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本 书 是 为 那些 对 分 片 感 兴趣 的 MongoDB 用 户 准 备 的 ， 它 全 面 讲述 了 如 何 建立 和 使 
用 集群 等 内 容 。 


本 书 不 是 对 MongoDB 的 入 门 介绍 。 读 者 需要 理解 诸如 文档 、 集 合 、 数 据 库 这 些 概 
念 ， 知 道 如 何 读 写 数据 ， 什 么 是 索引 ， 如 何以 及 为 什么 要 建立 副本 集 。 








如 果 你 并 不 熟悉 MongoDB， 大 可 不 必 担 心 ， 因 为 它 很 容易 上 手 。 市 面 上 有 一 些 有 
X MongoDB 的 书 ， 包 括 本 书 作 者 参与 编写 的 《MongoDB 权威 指南 》。 你 也 可 以 查 
阅 在 线 文档 。 


格式 约定 

本 书 使 用 了 如 下 排版 约定 。 
“楷体 

用 于 标记 新 名 词 。 


用 于 程序 代码 ， 在 段落 中 用 于 表示 程序 的 组 成 部 分 ， 如 变量 或 函数 名 、 数 据 库 、 数 
据 类 型 、 环 境 变 量 、 语 句 、 关 键 字 。 


令 或 是 其 他 应 该 由 用 户 输入 的 内 容 。 


=> 


XI 


。 等 宽 斜 体 


应 该 由 用 户 提供 的 或 根据 上 下 文 确定 的 值 。 


Va 
wey 








as 这 个 图 标 表示 提示 、 建 议 或 一 般 性 的 注解 。 


Ww F 
ASN 











-ED 这 个 图 标 表示 一 个 警告 或 警示 。 





使 用 示例 代码 

本 书 用 于 帮助 你 完成 工作 。 通 常 ， 你 可 以 在 程序 或 文档 中 使 用 本 书 提供 的 代码 。 除 
非 你 在 重新 发 布 我 们 的 大 量 代码 ， 否 则 不 需要 联系 我 们 来 获得 许可 。 比 如 ， 在 程序 
中 使 用 本 书 代码 的 一 些 片 段 是 无 需 我 们 许可 的 。 但 是 出 售 或 再 分 发 OReilly 的 图 书 
示例 光盘 显然 是 需要 授权 的 。 引 用 本 书 或 引用 示例 代码 来 回答 问题 是 不 需要 授权 的 ， 
但 将 本 书 的 大 量 示例 代码 纳入 产品 的 文档 是 需要 授权 的 。 


我 们 乐于 见 到 你 在 使 用 时 声明 引用 信息 ， 但 不 强制 要 求 。 引 用 信息 通常 包括 书 名 、 
作者 、 出 版 社 和 ISBN， 例 如 “Scaling MongoDB by Kristina Chodorow (O’Reilly). 
Copyright 2011 Kristina Chodorow, 978-1-449-30321-1”。 





























如 果 你 认为 对 示例 代码 的 使 用 需要 授权 ， 请 通过 这 个 邮箱 联系 我 们 : permissions@ 


oreilly.com, 








Safar" TRAE 
co} Safari 在 线 图 书 是 应 需 而 变 的 数字 图 书馆 。 它 能 够 让 你 非常 轻 
Safari. 松 地 搜索 7500 多 种 技术 性 和 创新 性 参考 书 以 及 视频 ， 以 便 快 
Books Online 。 速 地 找到 需要 的 答案 。 





订阅 后 你 就 可 以 访问 在 线 图 书馆 内 的 所 有 页 面 和 视频 ， 在 手机 或 其 他 移动 设备 上 阅 
读 ， 在 新 书 上 市 之 前 抢先 阅读 ， 还 能 够 看 到 尚 在 创作 中 的 书稿 并 向 作者 反馈 意见 。 
复制 粘贴 代码 示例 、 放 入 收藏 天 、 下 载 部 分 章节 、 标 记 关键 点 、 做 笔记 甚至 打印 页 
面 等 有 用 的 功能 可 以 帮 你 市 省 大 量 时 间 。 


这 本 书 也 在 其 中 。 欲 访问 本 书 的 英文 版 电子 版 ， 或 者 由 O’ Reilly 或 其 他 出 版 社 出 版 
的 相关 图 书 ， 请 到 http://my.safaribooksonline.com 免费 注册 。 

















-> 
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我 们 的 联系 方式 
版 社 。 


请 把 对 本 书 的 评论 和 问题 发 给 


美国 : 
O’Reilly Media, Inc. 
1005 Gravenstein Highway North 


Sebastopol, CA 95472 





中 国 : 
北京 市 西城 区 西直门 南大 街 2 号 成 铭 大 厦 C 座 807 室 (100035) 





奥 莱 利 技术 咨询 (北京 ) 有 限 公司 
区 的 网 站 地 址 是 : 





表 、 示 例 代码 以 及 其 他 信息 。 本 : 
http://oreilly.com/catalog/978 1449303211 


中 文书 : 
http://www.oreilly.com.cn/index.php?func=book&isbn=9787 115272119 


对 于 本 书 的 评论 和 技术 性 问题 ， 请 发 送 电 子 邮 件 到 : 
bookquestions @ oreilly.com 
关于 本 书 的 更 多 信息 、 会 议 、 资 源 中 心 和 网 络 ， 请 访问 以 下 网 站 : 
http://www.oreilly.com 
http://www.oreilly.com.cn 
我 们 在 Facebook 的 地 址 如 下 : 
http://facebook.com/oreilly 
请 关注 我 们 的 Twitter 动态 : 
http://twitter.com/oreillymedia 


我 们 的 YouTube 视频 地 址 如 下 : 


http://www.youtube.com/oreillymedia 


O'Reilly 的 每 一 本 书 都 有 专属 网 页 ， 你 可 以 在 那儿 找到 本 书 的 相关 信息 ， 包 括 勘误 
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欢迎 来 到 分 布 式 计 算 的 世界 


在 《终结 者 》 系 列 影 片 中 ， 一 个 称 作 “天 网 ”的 人 工 智 能 生命 向 人 类 发 动 成 争 ， 年 
复 一 年 地 制造 机 器 人 和 杀 死 人 类 。 这 是 大 部 分 运 维 人 员 的 梦想 ， 当 然 不 是 指 毁 天 人 
类 ， 而 是 指 构建 一 个 可 以 长 时 间 运 行 而 无 需 人 工 干预 的 分 布 式 系 统 。 遗 性 的 是 ， 时 
至 今日 “天 网 ”依旧 是 个 幻想 ， 因 为 设计 好 并 维护 其 稳定 持续 运行 ， 对 一 个 分 布 式 
系统 来 说 仍然 是 一 件 非常 困难 的 事情 。 


单 台 数据 库 服务 器 的 状态 通常 很 简单 : 非 局 即 停 。 但 是 如 果 再 添 一 台 服 务 器 并 把 数 
据 分 开 来 ， 则 这 两 台 服 务 器 之 间 会 产生 某 种 依赖 。 假 设 其 中 一 台 停 机 ， 对 另 一 台 会 
造成 什么 影响 ?你 的 应 用 程序 能 应 付 其 中 一 台 (或 两 台 一 起 ) 停机 的 情况 吗 ? 如果 
两 台 都 在 运行 但 无 法 通信 呢 ? 又 或 是 可 以 通信 ， 但 是 速度 非常 非常 慢 呢 ? 


随 着 更 多 市 点 被 添加 到 集群 里 ， 这 类 问题 会 变 得 越 来 越 多 和 复杂 。 如 果 集 群 中 的 一 
整 部 分 无 法 与 其 他 部 分 通信 会 发 生 什 么 ”如 果 一 部 分 机 器 月 涡 了 又 会 如 何 ? 如 果 整 
个 数据 中 心 都 出 问题 了 呢 ? 突然 之 间 ， 即 使 是 创建 一 个 备份 也 将 变 得 异常 困难 。 怎 
样 为 分 布 在 集群 中 几 十 台 机 器 上 的 TB 级 数据 建立 一 致 性 快照 ， 但 又 不 会 冻结 正在 
使 用 这 些 数据 的 应 用 程序 ? 


如 果 一 台 服 务 器 可 以 满足 需求 ， 那 就 能 避免 很 多 问题 。 但 是 如 果 想 要 存储 大 量 数 据 
或 者 想 以 高 于 单 服务 器 处 理 能 力 的 频率 来 访问 这 些 数据 ， 则 建立 一 个 集群 是 不 可 避 
免 的 。MongoDB 的 优势 之 一 正 是 试图 帮助 你 解决 上 面 列 出 的 许多 问题 。 不 过 这 并 
不 像 设 置 单个 mongod 实例 〈 这 又 是 什么 ? ) 那么 简单 。 本 书 将 向 你 展示 如 何 一 步 
步 建 立 起 一 个 健壮 的 集群 ， 以 及 在 这 个 过 程 中 将 遇 到 的 各 种 挑战 。 


什么 是 分 片 

分 片 (sharding) 是 MongoDB 用 来 将 大 型 集合 分 割 到 不 同 服务 器 (或 者 说 一 个 集 
群 ) 上 所 采用 的 方法 。 尽 管 分 片 起 源 于 关系 型 数据 库 分 区 ， 但 它 〈 像 MongoDB 的 
大 部 分 方面 一 样 ) 完全 是 另 一 回 事 。 
和 你 可 能 使 用 过 的 任何 分 区 方案 相 比 ，MongoDB 的 最 大 区 别 在 于 它 儿 乎 能 自动 完 
成 所 有 事情 。 只 要 告诉 MongoDB 要 分 配 数据 ， 它 就 能 自动 维护 数据 在 不 同 服务 器 
之 间 的 均衡 。 当 然 ， 你 得 告诉 MongoDB 把 服务 器 添加 到 集群 中 ， 不 过 只 要 这 么 做 
了 ，MongoDB 同样 会 确保 新 加 入 的 服务 器 分 得 均等 的 数据 。 


分 片 主要 是 为 了 实现 3 个 简单 的 目标 。 
























































让 集群 “不 可 见 ” 
应 用 程序 只 要 知道 跟 它 打交道 的 是 一 个 普通 的 mongod 实例 就 够 了 。 
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为 了 实现 这 一 目标 ，MongoDB 自 带 了 一 个 叫做 mongos 的 专 有 路 由 进程 。mongos 
坐镇 集群 大 前 方 ， 对 连 上 它 的 任何 应 用 而 言 就 像 是 一 个 普通 的 mongod 服务 器 。 
mongos 会 把 请 求 正 确 无 误 地 转发 到 集群 中 的 一 个 或 一 组 服务 器 上 ， 接 着 再 把 获得 的 
响应 拼装 起 来 发 回 给 客户 端 。 这 样 一 来 ， 客 户 端 无 需 知道 与 其 通信 的 是 一 台 服 务 器 
还 是 一 个 集群 。 


不 过 由 于 集群 本 身 的 特性 使 然 ， 也 存在 一 些 违背 该 抽象 的 特殊 情况 ， 这 些 特殊 情况 
会 在 第 4 章 中 提 到 。 











保证 集群 总 是 可 读 写 

任何 集群 都 无 法 保证 永远 可 用 〈 比 如 出 现 大 范围 停电 之 类 的 情况 )， 但 是 在 合理 的 条 
件 下 ， 永 远 都 不 应 该 出 现 用 户 无 法 读 写 数据 的 情况 。 在 功能 发 生 明显 降级 前 ， 集 群 
应 当 允 许 尽 可 能 多 的 市 点 失效 。 


MongoDB 通过 多 种 途径 来 确保 最 长 的 正常 运行 时 间 。 集 群 的 每 一 部 分 可 以 并 且 应 
当 在 其 他 服务 器 上 (最 理想 的 情况 是 在 其 他 数据 中 心 ) 有 宛 余 的 进程 运行 ， 以 便当 
一 个 进程 /机 器 /数据 中 心 坏 掉 了 ， 其 他 副本 可 以 立即 (自动 地 ) 接替 坏 掉 的 部 分 
继续 工作 。 


把 数据 从 一 台 服 务 器 迁移 到 另 一 台 的 过 程 中 也 存在 着 一 个 非常 有 趣 的 难题 : 在 传 
输 过 程 中 如 何 保证 对 数据 访问 的 持续 性 和 一 致 性 ? 我 们 已 经 找 出 了 一 些 非常 好 的 
解决 方案 ， 不 过 有 些 超 出 本 书 的 讲述 范围 。 总 之 ，MongoDB 采用 了 一 些 非常 漂亮 
的 技巧 。 
































使 集群 易于 扩展 
当 系统 需要 更 多 的 空间 或 资源 时 ， 应 当 可 以 添加 。MongoDB 支持 按 需 扩充 系统 容 
量 。 有 关 增 加 〈 和 移 除 ) 容量 的 更 多 内 容 参 见 第 3 章 。 


要 实现 这 些 目 标 ， 一 个 集群 应 该 易于 使 用 (就 像 使 用 单个 市 点 一 样 ) 和 易于 管理 
(否则 添加 新 的 分 片 就 不 那么 容易 了 )。MongoDB 能 够 轻而易举 地 让 应 用 程序 自然 
ALLE BC 
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理解 分 片 


为 了 建立 、 管 理 或 调试 集群 ， 需 要 了 解 分 片 的 基本 工作 模式 。 本 章 包 含 这 部 分 基本 
内 容 以 便 你 理解 所 发 生 的 事情 。 


2.1 分 割 数据 
DA (shard) 是 集群 中 负责 数据 基 一 子 集 的 一 台 或 多 台 服 务 器 。 举 个 例子 ， 如 果 有 一 


个 集群 存储 了 1 000 000 份 代表 网 站 用 户 的 文档 ， 则 一 个 分 片 可 能 包含 其 中 200 000 位 
用 户 的 信息 。 


一 个 分 片 可 由 多 台 服 务 器 组 成 。 如 果 分 片 包含 不 止 一 台 服 务 器 ， 则 每 台 服 务 
一 份 完全 相同 的 数据 子 集 的 副本 CULE 2-1)。 在 生产 环境 中 ， 一 个 分 片 通常 
副本 集 (replica set). 


都 有 
ss 


ay 
是 一 人 

















图 2-1: 一 个 分 片 包含 数据 的 某 一 子 集 。 若 某 一 分 片 包含 多 台 服 务 器 ， 则 每 台 服 务 器 拥有 一 
份 完整 的 数据 副本 


为 了 在 分 片 间 均匀 地 分 配 数据 ，MongoDB 会 在 不 同 分 片 间 移 动 数据 子 集 。 它 会 根 
据 片 键 (key) 来 决定 移动 哪些 数据 。 例 如 我 们 可 能 选择 按 用 户 名 (username) 字段 
来 划分 用 户 集合 。MongoDB 使 用 基于 区 间 的 方法 进行 划分 ， 即 按照 给 定 区 间 将 数 
据 分 割 成 不 同 块 ， ena "f")。 本 章 会 使 用 标准 的 区 间 符 号 来 描述 区 间 。“[” 和 
“]” 表 示 闭 区 间 ， 而 “(” “)” 表 示 开 区 间 。 因 此 ， 有 4 种 可 能 的 区 间 : 


x 在 (a,b) 中 ， 当 且 仅 当 存 在 x 使 得 a <x<5b。 
x 在 (a,b), 4AM 4 FEE x (EG a<x <b, 
x 在 [a,5) 中 ， 当 且 仅 当 存 在 x 使 得 a <x<b, 
x 在 [a,5] 中 ， 当 且 仅 当 存 在 x 使 得 a < x <b, 


MongoDB 中 分 片 多 用 [a, b) 来 表示 区 间 范 围 ， 所 以 这 最 常见 的 形式 。 该 区 间 
可 以 表述 为 “从 a 开始 且 包含 gc， 到 了 为 止 但 不 包含 p”。 


举 个 例子 ， 比 如 说 我 们 有 一 个 用 户 名 区 间 ["a"y"f")， 那 么 "a"、"charlie"， 以 
及 "ez-bake" 都 可 能 属于 这 一 区 间 对 应 的 集合 ， 因 为 按 字符 串 比 较 有 "a" < "a"< 
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"charlie"<"ez-bake"<"f£", 


该 区 间 的 范围 到 "f" 为 止 但 不 包含 vf"， 因 此 "ez-bake" 可 能 属于 这 一 集合 ， 而 
"E 不 属于 。 


2.1.1 分 配 数据 
MongoDB 划分 数据 的 方法 有 些 不 直观 。 为 了 理解 这 么 做 的 理由 ， 我 们 先 使 用 初级 
方法 ， 遇 到 问题 时 再 寻找 更 好 的 方法 。 


1. 一 分 片 一 区 间 

分 配 数据 到 分 片 最 简单 的 方法 就 是 让 每 个 分 片 负 责 一 个 区 间 的 数据 。 所 以 ， 如 果 我 
们 有 4 个 分 片 ， 则 很 可 能 会 得 到 如 图 2-2 所 示 的 设置 。 在 这 个 例子 里 ， 我 们 假设 所 
有 用 户 名 都 以 "a" 到 "z" 之 间 的 字母 开头 ， 其 范围 可 以 表示 为 区 间 (va, "{"), 
{ 是 ASCII 码 表 中 字母 z 后 面 的 字符 。 








["a" $ "f") "f" 5 "n") ["n" ; "t") ['t" A mn) 


分 片 1 分 片 2 分 片 3 分 片 4 














B 2-2; 4 个 分 片 ， 其 区 间 分 别 是 ["a","f"), ["f","n"), ["n","t") 和 ["e","{") 


Ma FR ARATE 8 HHD E, Ee FE — PKI SEP AA RE & A ME 
推 想 如 此 分 片 导致 的 后 果 ， 就 很 容易 明白 其 中 的 道理 。 


假设 许多 用 户 用 首 字母 在 范围 [van "f") 中 的 名 字 来 注册 。 这 会 导致 分 片 1 较 大 ， 
因此 我 们 需要 拿 出 它 的 一 部 分 文档 并 将 其 挪 到 分 片 2 上去。 我 们 可 以 调整 区 间 使 分 
Fl (比方 说 ) 变 成 [ra"，"c") ， 使 分 片 2 变 成 Teen, one) ( 见 图 2-3)。 


目前 好 像 没 什么 问题 ， 但 如 果 分 片 2 因此 过 载 该 怎么 办 呢 ? 假设 分 片 1 和 分 片 2 各 
有 500 GB 数据 ， 而 分 片 3 和 分 片 4 各 自 只 有 300 GB。 那 么 按照 这 个 分 片 方 案 ， 则 
最 终 要 进行 一 连 串 复制 : 我 们 不 得 不 把 100 GB 数据 从 分 片 1 挪 到 分 片 2， 接 着 把 
200 GB 数据 从 分 片 2 挪 到 分 片 3， 最 后 再 把 100 GB 数据 从 分 片 3 挪 到 分 片 4， 算 
下 来 总 共 要 挪动 400 GB 数据 ( 见 图 2-4) 。 考 虑 到 所 有 数据 移动 都 必须 在 集群 中 级 
联 下 去 ， 可 知 额外 移动 的 数据 量 很 大 。 
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rei" 


[ a 9 f ) ["f" ` "n") ["n" ; "t") ['t" > mr") 
分 片 2 分 片 3 分 片 4 


["a" ; "ce") ["c" x "n") ["n" ; "t") Pr: ; "{") 
ay 分 片 2 分 片 3 分 片 4 














B 2-3: 从 分 片 1 迁移 部 分 数据 到 分 片 2。 分 片 1 的 区 间 缩 小 而 分 片 2 的 区 间 扩大 


500 GB 500 GB 300 GB 300 GB 


100 GB 


ra “a 
400 GB 600 GB 300 GB 300 GB 


200 GB 


P “a 
400 GB 400 GB 500 GB 300 GB 


100.68 


400 GB 400 GB 400 GB 400 GB 


B 2-4: 一 分 片 一 区 间 会 导致 级 联 效应 ;必须 移动 数据 到 “下 一 台 ” 服 务 器 上 ， 即 使 不 能 改 
善 平衡 性 
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如 果 添 加 一 个 新 分 片 又 会 怎样 呢 ?” 假 设 这 个 集群 继续 工作 下 去 ， 最 终 每 个 分 片上 都 
有 了 500 GB 数据 ， 然 后 我 们 添加 一 个 新 分 片 进 来 。 现 在 我 们 不 得 不 把 400 GB 数据 
从 分 片 4 挪 到 分 片 5， 将 300 GB 从 分 片 3 挪 到 分 片 4， 将 200 GB 从 分 片 2 挪 到 分 
片 3， 将 100 GB 从 分 片 1 挪 到 分 片 2 ( 见 图 2-5)。 整 整 移动 了 1 TB 数据 | 











400 GB 400 GB 400 GB 400 GB 400 GB 











图 2-5: 添加 一 台新 服务 器 并 使 集群 负载 均衡 。 我 们 可 以 通过 在 集群 的 “中 间 ”( 分 片 2 和 分 
片 3 之 间 ) 添加 服务 器 来 降低 所 需 迁 移 的 数据 量 ， 但 即使 这 样 仍然 需要 迁移 600 GB 数据 


随 着 分 片 数 量 和 数据 量 的 增长 ， 这 种 级 联 效 应 只 会 持续 恶化 下 去 。 因 此 MongoDB 
并 不 采用 这 种 方法 来 分 配 数据 ， 而 是 使 每 个 分 片 包含 多 个 区 间 。 


2. 一 分 片 多 区 间 
让 我 们 回头 重新 考虑 如 图 2-4 所 示 的 情况 ， 其 中 分 片 1 和 分 片 2 各 有 500 GB 数据 ， 
而 分 片 3 和 分 片 4 各 有 300 GB 数据 。 这 次 我 们 允许 每 个 分 片 包含 多 块 区 间 。 


我 们 可 以 把 分 片 1 上 的 数据 划分 为 两 个 区 间 ， 使 其 中 一 个 包含 400 GB 数据 (比如 
说 ["a "md"))， 男 一 个 包含 100 GB 数据 (["a","f"))。 接 着 我 们 对 分 片 2 也 
做 同样 的 处 理 , 得 到 区 间 Cee", wj") 和 [rj","n")。 现 在 可 以 把 100 GB 数据 
(Cran, "e£")) 从 分 片 1 迁移 到 分 片 4 上 ， 把 区 间 Ong", nm") 内 的 所 有 文档 从 分 片 
2 迁移 到 分 片 3 (WA 2-6)。 一 个 区 间 的 数据 称 为 一 个 数据 块 (也 叫 块 ，chunk)。 
当 我 们 把 一 个 块 的 区 间 一 分 为 二 时 ， 一 个 块 也 变 成 了 两 个 块 。 


这 样 每 个 分 片上 就 有 了 400 GB 数据 ， 而 仅 有 200 GB 数据 需要 挪动 。 


如 果 要 添加 新 分 片 ，MongoDB 可 以 从 每 个 分 片 顶 端 取 100 GB 数据 并 把 这 些 块 挪 
到 新 分 片上 ， 使 得 新 分 片 获取 400 GB 数据 需要 移动 的 数据 量 最 小 化 : 只 有 400 GB 
(LEI 2-7). 
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500 GB 500 GB 300 GB 300 GB 
分 片 1 分 片 2 分 片 3 分 片 4 










400 GB 400 GB 400 GB 
分 片 2 分 片 3 分 片 4 











图 2-6: 让 分 片 支持 多 重 非 连续 区 间 ， 我 们 便 可 以 挑选 数据 并 将 其 移动 到 任何 地 方 





500 GB 500 GB 500 GB 
分 片 1 分 片 2 分 片 3 


Vvvy 


400 GB 400 GB 400 GB 


分 片 1 分 斤 3 分 片 4 分 斤 5 











2-7: 添加 新 分 片 时 ， 每 个 分 片 都 可 以 直接 给 它 提供 数据 

这 就 是 MongoDB 的 数据 分 配 之 道 。 当 一 个 块 变 得 越 来 越 大 时 ，MongoDB 会 自动 将 
其 分 割 成 两 个 较 小 的 块 。 如 果 分 片 间 比 例 失 调 ， 则 MongoDB 会 通过 迁移 块 来 确保 
均衡 。 


2.1.2 如何 创建 块 

当 你 决定 分 配 数据 时 ， 必 须 为 块 区 间 选 择 一 个 键 (前 面 我 们 一 直 在 用 username ) 。 
这 个 键 叫做 片 键 (shard key)， 片 键 可 以 是 任意 字段 或 字段 的 组 合 。( 第 3 章 会 介绍 
如 何 选择 片 键 以 及 对 集合 进行 分 片 的 命令 。) 
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1. 示例 
假如 我 们 的 集合 中 包含 如 下 文档 〈 忽 略 _id 字段 ) : 


{"username" : "paul", "age" : 23} 
{"username" : "simon", "age" : 17} 
{"username" : "widdly", "age" : 16} 
{"username" : "scuds", "age" : 95} 
{"username" : "grill", "age" : 18} 
{"username" : "flavored", "age" : 55} 
{"username" : "bertango", "age" : 73} 
{"username" : "wooster", "age" : 33} 


如 果 我 们 选择 age 字段 作为 片 键 并 得 到 一 个 块 区 间 [15, 26)， 则 此 块 会 包含 以 下 文档 : 





{"username" : "paul", "age" : 23} 

{"username" : "simon", "age" : 17} 
{"username" : "widdly", "age" : 16} 
{"username" : "grill", "age" : 18} 


如 你 所 见 ， 这 个 块 中 的 所 有 文档 其 age 字段 值 都 在 这 个 块 的 区 间 内 。 


2. 对 集合 分 片 

对 一 个 集合 分 片 时 ， 无 论 集 合 里 有 什么 数据 MongoDB 都 只 会 创建 一 个 块 。 这 个 块 
的 区 间 是 (- < , ce)， 其 中 - 是 MongoDB 可 以 表示 的 最 小 值 〈 也 叫 heel 
co 是 最 大 值 (也 叫 SmaxKey) 。 





we 如 果 被 分 片 的 集合 中 包含 大 量 数据 ，MongoDB 会 立刻 把 这 个 初始 块 分 割 为 
N 多 个 较 小 的 块 。 





事实 上 ， 由 于 上 面 例子 中 的 集合 太 小 并 不 能 触发 分 割 ， 所 以 在 插入 更 多 数据 之 前 ， 
都 只 有 一 个 块 (-  , %)。 尽 管 如 此 ， 为 了 达到 演示 的 目的 ， 我 们 假设 这 个 数据 量 
已 经 足够 大 了 。 


MongoDB 会 把 初始 块 (- se , ce ) 分 割 为 两 个 新 块 ， 分 割 位 置 一 般 选 在 已 有 数据 区 
间 的 中 点 附近 。 因 此 ， 如 果 大 约 一 半 文 档 的 age 字段 值 小 于 15, HA-EAF 15, 
MongoDB 就 很 可 能 会 选择 15。 这 样 就 得 到 两 个 块 : (- ce ,15] 和 [15, ©) ( 见 图 
2-8)。 如 果 我 们 往 块 [15,  ) 里 继续 插入 数据 ， 它 会 再 一 次 被 分 割 〈 比 如 说 分 割 成 
[15,26) 和 [26, ce )) 。 这 样 集合 中 就 有 了 3 个 块 : (- © ,15)、[15,26) 和 [26, œ). 
在 插入 更 多 数据 的 同时 ，MongoDB 会 持续 地 将 已 有 块 分 割 成 更 多 的 新 块 。 


块 的 区 间 可 以 只 包含 一 个 值 ( 例 如 仅 包含 用 户 名 为 paul 的 用 户 )， 但 是 各 块 的 区 间 
必须 互 不 相同 (不 能 有 两 个 块 的 区 间 同 为 ["a","f"))。 另 外 ， 也 不 能 有 区 间 相 互 重 
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县 的 块 ， 而 且 每 个 块 的 区 间 必 须 紧 邻 下 一 个 块 的 区 间 。 因 此 如 果 要 分 割 一 个 区 间 为 
[4,8) 的 块 ， 结 果 可 以 是 [4,6) 和 [6,8) (因为 二 者 合 起 来 能 覆盖 原 块 的 区 间 )， 但 不 
可 以 是 [4,5) 和 [6,8) (因为 这 样 集合 将 丢失 区 间 (5.6) 中 的 所 有 数据 )， 也 不 能 是 
[4,6) 和 [5,8) (因为 会 造成 块 的 部 分 重合 )。 每 个 文档 必须 属于 且 仅 属于 一 个 块 。 





© 

















2-8: 一 个 块 分 割 成 两 个 块 


由 于 MongoDB 不 强制 要 求 任何 形式 的 结构 定义 ， 你 可 能 会 纳 问 : 那 没 有 值 可 以 作 
为 片 键 的 文档 会 被 放 到 哪里 去 呢 ? 实际 上 MongoDB 并 不 允许 插入 无 片 键 的 文档 
(尽管 使 用 null 作为 片 键 值 是 可 以 的 )， 也 不 允许 修改 文档 的 片 键 值 (例如 用 $set 
命令 )。 给 文档 一 个 新 片 键 的 唯一 方法 是 先 删 除 文档 ， 然 后 在 客户 端 修改 片 键 的 值 ， 
再 重新 插入 文档 。 


如 果 在 一 些 文档 中 使 用 字符 串 ， 而 在 另 一 些 文档 中 使 用 数字 呢 ? 这 也 是 可 以 的 ， 因 
为 在 MongoDB 中 类 型 之 间 有 严格 的 次 序 。 如 果 在 age 字段 插入 一 个 字符 串 〈 或 数 
组 、 布 尔 值 、null 等 )，MongoDB 会 按照 类 型 对 甚 排序。 类 型 的 先后 次 序 如 下 : 


null < 数字 < 字符 串 < 对 象 < 数组 < 二 进 制 数据 < Objectid < 布尔 值 < 日 期 < 正则 
表达 式 


在 同一 种 类 型 内 ， 排 序 与 你 所 期 望 的 很 可 能 相同 : 2 < 4 或 "ar<"z"。 
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在 前 面 的 第 一 个 例子 里 ， 块 都 是 几 百 GB 大 小 ， 但 在 真实 系统 中 ， 块 大 小 默认 仅 有 
200 MB。 这 是 因为 挪动 数据 的 代价 非常 大 ， 要 花费 很 长 时 间 ， 占 用 系统 资源 ， 而 且 
会 明显 增加 网 络 流量 。 你 可 以 自己 试 试看 ， 先 插入 200 MB 数据 到 某 一 集合 中 ， 然 
后 试 着 取 回 所 有 200 MB 数据 。 接 着 想象 一 下 在 建 有 多 个 索引 (比如 生产 系统 很 可 
能 有 多 个 索引 ) 的 系统 上 做 同样 的 事情 ， 同 时 该 系统 上 还 有 其 他 数据 流量 存在 的 情 
况 。 你 肯定 不 会 愿意 看 着 应 用 程序 逐渐 降低 性 能 直至 停止 ， 而 MongoDB 还 在 后 台 
拖 拖 拉 拉 地 挪动 数据 。 实 际 上 ， 如 果 一 个 块 过 大 ，MongoDB 根本 就 不 会 移动 它 。 
反 过 来 你 也 不 会 希望 块 过 小 ， 因 为 每 个 块 都 需要 有 一 点 点 管理 开销 (以便 你 不 必 为 
跟踪 不 计 其 数 的 数据 块 而 烦恼 )。 综 合 考 虑 之 下 ， 我 们 发 现 200 MB 恰好 是 兼顾 可 移 
动 性 和 最 小 开销 的 最 佳 选择 。 


























块 是 一 个 逻辑 概念 ， 而 非 物理 实现 。 一 个 块 中 的 文档 在 物理 上 并 不 连续 存 
心 。 储 于 磁盘 上 或 以 任何 形式 聚集 在 一 起 。 它 们 可 能 分 散在 整个 集合 的 任何 角 
BEY 落 里 。 一 个 文档 属于 一 个 块 当 且 仅 当 其 片 键 值 在 对 应 的 块 区 间 内 。 





























2.2 平衡 

如 果 存 在 多 个 可 用 的 分 片 ， 只 要 块 的 数量 足够 多 ，MongoDB 就 会 把 数据 迁移 到 其 
他 分 片上 。 这 个 迁移 过 程 叫做 平衡 (balancing)， 由 叫做 平衡 器 (balancer) 的 进程 
负责 执行 。 


平衡 器 会 把 数据 块 从 一 个 分 片 挪 到 另 一 个 分 片上 ， 其 优点 在 于 自动 化 ， 即 你 无 需 担 
心 如 何 保持 数据 在 分 片 间 的 均匀 分 布 ， 这 项 工作 已 经 由 平衡 器 替 你 搞定 了 。 不 过 这 
也 是 它 的 缺点 ， 因 为 自动 意味 着 如 果 你 不 喜欢 它 做 负载 均衡 的 方式 ， 那 只 能 算 你 不 
走运 。 如 果 不 想 让 某 个 块 存 在 于 分 片 3 上 ， 你 可 以 把 它 手动 移动 到 分 片 2 上 ， 但 是 
平衡 器 很 可 能 把 它 再 挪 回 分 片 3。 你 只 能 选择 要 么 对 集合 重新 分 片 (re-shard) ， 要 
么 关闭 平衡 化 。 

在 写 这 本 书 时 ， 平 衡器 的 算法 还 不 是 很 智能 。 它 每 天 基于 分 片 整 体 大 小 来 移动 块 。 
在 (不久 的 ) 将 来 它 会 变 得 更 加 先进 。 

平衡 器 的 目标 不 仅 是 要 保持 数据 均匀 分 布 ， 还 要 最 小 化 被 移动 的 数据 量 。 因 此 触发 
平衡 器 需要 很 多 条 件 。 要 触发 一 轮 平衡 ， 一 个 分 片 必须 比 块 最 少 的 分 片 多 出 至 少 9 
个 块 。 到 那 时 ， 块 就 会 被 迁移 出 拥挤 的 分 片 ， 直 到 与 其 他 分 片 平 衡 为 止 。 

平衡 器 并 不 非常 激进 的 原因 在 于 MongoDB 希望 能 避免 将 相同 数据 来 回 移动 。 如 果 
平衡 器 要 平衡 掉 每 一 点 微小 的 差别 ， 那 很 可 能 会 不 停 地 浪费 资源 : 分 片 1 比分 片 2 
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多 两 个 块 时 ， 它 就 发 送 一 个 块 给 分 片 2。 接 着 一 些 写 操作 落 到 分 片 2 上 ， 使 得 分 片 2 
又 比分 片 1 多 出 两 个 块 ， 结 果 同 一 块 数据 又 被 折腾 回去 (ILE 2-9)。 通 过 等 待 更 严 
重 的 不 平衡 发 生 ，MongoDB 能 够 最 小 化 无 意义 的 数据 传输 。 要 知道 差 9 个 块 其 实 
也 不 是 那么 不 平衡 ， 因 为 这 还 不 到 2 GB 数据 呢 。 








时 间 流 逝 


50 块 
4} Fy 2 














82-9: 如 果 每 一 点 轻微 的 不 平衡 都 被 修正 ， 则 最 终 必然 导致 大 量 不 必要 的 数据 移动 


3. 每 日 平衡 背后 的 病理 心理 学 

大 部 分 用 户 和 希望 通过 看 到 数据 移动 来 向 自己 证 明 分 片 可 以 工作 ， 这 产生 了 一 个 癌 题 : 
触发 一 轮 平 衡 所 需 的 数据 量 远 比 大 多 数 人 想象 的 大 。 

比方 说 我 正在 尝试 分 片 ， 于 是 写 了 一 个 命令 行 脚本 来 插入 50 万 份 文档 到 分 片 集 
合 中 : 
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> for (i=0; i<500000; i++) { 
db.foo.insert ({" id" 2 oi, "x" : 1,"y" : 2, "Zz" : i, "date" : new Date(), 
"Foo" : "bar"}) ; 


} 


等 插入 完成 ， 我 应 该 能 看 见 一 些 数 据 飞 来 飞 去 了 ， 对 不 对 ? 错 。 如 果 我 看 一 眼 数据 
库 状态 ， 就 会 发 现 还 差 得 远 呢 〈 为 了 清楚 省 略 了 一 些 字段 ) : 





> db.stats() 
{ 
"raw" : { 
"ubuntu:27017" : f 
/* 分 片 状态 */ 
}, 
"ubuntu:27018" : { 


/* 分 片 状态 */ 





} 


}, 

"objects" : 500008, 

"avgObjSize" : 79.99937600998383, 
"dataSize" : 40000328, 
"StorageSize" : 69082624, 

vok s T 


} 


如 果 你 看 一 眼 aatasize， 可 以 发 现 有 40 000 328 字 节 的 数据 ， 大 致 等 于 40 MB, 
这 还 不 够 一 个 块 。 甚 至 还 不 够 一 个 块 的 1/4 ! 真 要 想 看 到 数据 移动 的 话 ， 需 要 插入 
2 GB 数据 ， 也 就 是 2500 万 个 这 样 的 文档 ， 或 者 说 是 现在 已 插入 数据 的 50 倍 。 


开始 使 用 分 片 时 ， 人 们 希望 看 到 数据 到 处 移动 ， 这 是 人 的 本 性 使 然 。 尽 管 如 此 ， 在 
生产 系统 中 你 不 会 希望 发 生 太 多 迁移 ， 因 为 这 种 操作 代价 极其 高 郧 。 因 此 ， 一 方面 
我 们 希望 看 到 迁移 实际 发 生 ， 而 另 一 方面 ， 事实 又 是 如 果 它 不 是 看 上 去 慢 得 让 人 烦 
躁 ， 就 不 可 能 工作 得 很 好 。 


对 这 个 矛盾 ，MongoDB 需要 实现 两 个 “技巧 "， 让 分 片 更 加 善 解 人 意 ， 同 时 又 不 对 
生产 系统 造成 破坏 性 影响 。 














技巧 1: 自 定义 块 大 小 


第 一 次 启动 mongos 时 ， 可 以 声明 - -chunksize NBR, Kb 就 是 你 想 要 的 块 
大 小 ， 单 位 是 MB 。 如 果 只 是 想 试 试 分 片 ， 可 以 设置 - -chunksize 1， 这 样 只 要 插 
AJL MB 的 数据 就 能 看 到 迁移 发 生 。 


技巧 2: 递增 块 大 小 
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Atk, MongoDB 会 特意 自动 降低 块 大 小 ， 从 200 MB 降 到 64 MB ， 而 这 就 是 为 了 更 
好 地 照顾 一 下 用 户 的 感受 。 一 旦 数据 块 多 起 来 ， 它 会 自动 把 块 大 小 递增 回 200 MB. 


改变 块 大 小 

块 大 小 可 以 通过 在 启动 时 指定 - -chunksize N 参数 或 修改 config.settings 集合 并 整 
体 性 重启 来 改变 。 尽 管 如 此 ， 除 非 是 为 了 好 玩 试 试 1 MB 的 块 大 小 ， 请 勿 随意 改动 
块 大 小 。 


我 可 以 保证 ,无论 你 正在 尝试 解决 什么 问题 ， 摆 弄 块 大 小 绝 不 是 根本 的 解决 之 道 。 
它 看 上 去 很 诱 人 ， 但 请 勿 这 么 做 。 除 非 你 只 是 想 设置 --chunksize 1 试 试 ， 否则 
请 保持 块 大 小 不 变 。 


2.3 mongos 


mongos 是 用 户 和 集群 间 的 交互 点 , 其 职责 是 隐藏 分 片 内 部 的 复杂 性 并 向 用 户 (你 ) 
提供 一 个 简洁 的 单 服务 器 接口 。 这 个 抽象 层 中 也 存在 一 些 “ 颖 隙 ”( 参 见 第 4 章 )， 
不 过 大 多 数 情况 下 mongos 允许 你 把 一 个 集群 当 作 一 台 服务 器 。 

使 用 集群 时 ， 应 该 连接 一 个 mongos 并 向 它 发 送 所 有 的 读 写 操作 。 无 论 如 何 ， 你 都 
不 应 该 直接 访问 分 片 〈 但 如 果 想 的 话 能 做 到 ) 。 

mongos 会 将 所 有 用 户 请 求 转发 到 恰当 的 分 片上 。 如 果 用 户 插入 一 份 文档 ，mongos 
会 查看 文档 的 片 键 ， 对 照 数据 块 ， 并 把 文档 发 送 到 持 有 相应 块 的 分 片上 。 

举 个 例子 ， 比 如 说 我 们 要 插入 {"foo": "bar"} 且 已 经 以 foo 作为 片 键 做 了 分 片 。 
mongos 会 查看 所 有 可 用 的 块 ， 然 后 发 现 有 一 个 区 间 为 [varwe") 的 块 应 当 包含 
"par"。 这 个 块 在 分 片 2 上 ， 因 此 mongos 会 把 插入 消息 发 送 给 分 片 2 ( 见 图 2-10)。 

















{ "foo":"bar" } eke 











2-10: 把 一 个 请 求 路 由 到 包含 对 应 块 的 分 片上 
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如 果 一 个 查询 涉及 了 片 键 ，mongos 就 可 以 使 用 和 插入 一 样 的 流程 并 找到 某 个 (或 
某 些 ) 正确 的 分 片 并 癌 其 发 送 查询 。 这 种 查询 又 称 为 针对 性 查询 (targeted query), 
因为 它 只 针对 那些 可 能 包含 我 们 所 要 查找 的 数据 的 分 片 。 如 果 ee Ai 
{"foo":"bar"}， 那 么 查询 所 含 片 键 值 大 于 "bar" 的 分 片 就 没有 什么 


如 果 查 询 不 包含 片 键 ，mongos 就 必须 把 查询 发 送 给 所 有 分 片 。 这 可 能 会 比 针 对 性 查 
询 效 率 低 ， 但 并 不 一 定 。 如 果 一 个 泛泛 的 查询 仅 访问 内 存 中 少量 已 被 索引 的 文档 ， 
而 一 个 针对 性 查询 不 得 不 访问 分 布 在 多 个 (甚至 所 有 ) 分 片 中 的 磁盘 数据 ， 两 相 比 
较 ， 前 者 的 性 能 肯定 要 比 后 者 高 得 多 。 


2.4 配置 服务 器 


mongos 进程 并 不 持久 地 存储 任何 数据 ， 集 群 配置 被 保存 在 一 组 专门 的 mongod E, 
它们 被 称 作 配置 服务 器 (config server) 。 配 置 服务 器 包含 了 有 关 集 群 的 最 完整 可 靠 
的 信息 以 供 所 有 人 (分 片 、mongos 进程 和 系统 管理 员 ) 访问 。 


要 保证 数据 块 迁移 成 功 ， 所 有 配置 服务 器 都 必须 同时 在 线 。 如 果 其 中 任意 一 台 停 机 
了 ， 则 当前 正在 执行 的 所 有 迁移 都 会 回 退 并 停止 ， 直 到 整套 配置 服务 器 再 一 次 运行 
起 来 。 任 何 一 台 配 置 服务 器 停机 ， 集 群 配置 都 无 法 改变 。 


2.5 ”集群 的 构造 

















一 个 MongoDB 集群 基本 上 由 3 类 进程 组 成 ， 即 实际 存储 数据 的 分 片 、 负 责 把 请 求 
路 由 到 正确 数据 的 mongos 进程 ， 以 及 用 于 跟踪 集群 状态 的 配置 服务 器 ( 见 图 2-11 





和 图 2-12). 





集群 配置 一 一 


配置 服务 器 














图 2-11: 一 个 集群 的 3 个 组 件 
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B 2-12: 每 个 组 件 可 以 包含 多 个 进程 


以 上 每 个 组 件 都 不 是 “一 台 机 器 *"。mongos 进程 通常 跑 在 应 用 程序 服务 器 (appserver) 
上 。 配 置 服务 器 ， 鉴 于 其 重要 性 ， 是 非常 轻 量 级 的 并 且 基 本 上 可 以 在 任何 机 器 上 运 
行 。 每 个 分 片 通常 由 多 台 机 器 组 成 ， 因 为 它们 实际 存储 数据 。 
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建立 集群 


3.1 选择 片 键 


选择 一 个 好 的 片 键 非常 关键 。 如 果 选 择 了 一 个 糟糕 的 片 键 ， 它 可 以 立马 或 者 在 访问 
量变 大 时 毁 了 你 的 应 用 程序 ， 也 有 可 能 潜伏 着 ， 等 待 着 ， 没 准 儿 什么 时 候 突然 毁 了 
你 的 应 用 程序 。 


另 一 方面 ， 如 果 你 选择 了 一 个 好 片 键 ， 只 要 应 用 程序 还 在 正常 运行 ， 而 且 只 要 发 现 
访问 量 提高 就 赶紧 添 服务 器 ，MongoDB 就 会 确保 一 直 正 确 地 运行 下 去 。 


正如 在 上 一 章 中 所 学 的 ， 片 键 决 定 了 数据 在 集群 中 的 分 布 情况 。 因 此 你 会 希望 存在 
这 样 一 个 族 键 ， 它 既 能 把 读 写 分 散 开 来 ， 又 能 把 正在 使 用 的 数据 保持 在 一 起 。 这 些 
看 似 相互 矛盾 的 目标 在 现实 中 却 往 往 是 可 以 实现 的 。 


我 们 先 挑 片 键 的 几 个 反面 例子 找 找茬 ， 然 后 再 拿 几 个 较 好 的 例子 来 琢磨 一 番 。 
MongoDB 的 wiki 上 也 有 一 页 与 选择 片 键 相 关 且 很 不 错 的 内 容 ， 可 以 看 看 。 


3.1.1 小 基数 片 键 
一 些 人 并 不 真正 理解 或 者 信任 MongoDB 自动 分 配 数据 的 方式 ， 所 以 他 们 总 是 沿 着 
这 人 么 个 思路 来 想 :“ 我 有 4 个 分 片 ， 所 以 应 该 用 一 个 有 4 个 可 能 值 的 字段 来 做 片 键 。 
这 是 一 个 非常 糟糕 的 想法 。 


为 什么 呢 ? 


假设 我 们 有 一 个 存储 用 户 信息 的 应 用 程序 。 每 个 文档 有 一 个 continent 字段 
代表 用 户 的 所 在 地 区 ， 其 字段 值 可 以 是 "Africa"、"Antarctica"、"Asia'.、 
"Australia", "Europe", "North America" K "South America", 考虑 到 我 
们 在 每 个 大 洲 都 有 一 个 数据 中 心 一 一 或 许 不 包括 南极 洲 (Antarctica) 并 且 想 从 
人 们 所 在 “当地 ”的 数据 中 心 为 其 提供 用 户 数据 ， 我 们 决定 按 该 字段 进行 分 片 。 


集合 开始 于 某 个 数据 中 心 的 一 个 分 片 的 初始 块 (区间 (- = , 22 ))， 所 有 的 插入 和 
读 取 都 落 在 这 一 个 块 上 。 一 旦 它 变 得 足够 大 ， 就 会 被 划分 成 两 个 块 ( 区 间 分 别 为 
(- © ,"Europe") 和 ["Europe", © ))。 这 样 一 来 ， 所 有 来 自 非 洲 (Africa) 、 南 极 
洲 (Antarctica)、 亚 洲 (Asia) 或 澳大利亚 (Australia) 的 文档 都 会 被 分 到 第 一 块 
上 上， 而 所 有 来 自 欧 洲 (Europe)、 北 美 (North America) 或 南美 (South America) 
的 数据 都 会 被 分 到 第 二 块 上 。 随 着 更 多 文档 被 添加 进来 ,集合 最 终 会 变 成 7 个 块 
( 见 图 3-1) : 
































(一 ce ,"Antarctica") 


["Antarctica","Asia") 
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"Asia", "Australia") 


"Australia", "Europe") 


[ 
[ 

°. ["Europe","North America") 
["North America", "South America") 
[ 


"South America", © ) 











["N. America", § ["S. America", 
"S, America") J co) 


["Australia", 


[-e0, ["Antartica", 
"Antartica") 目 "Asia") 


["Asia", 


["Europe", 


"Australia") "Europe") "N. America") 














3-1: 每 个 大 洲 一 个 分 片 
然后 呢 ? 


MongoDB 不 能 再 进一步 分 割 这 些 块 了 ! 块 只 能 变 得 越 来 越 大 。 虽 然 暂时 不 会 出 问 
题 ， 但 是 当 服 务 器 磁盘 空间 开始 逐渐 耗 尽 时 间 题 就 会 浮 出 水 面 了 。 除 了 买 块 更 大 的 
磁盘 ， 你 什么 也 做 不 了 。 


由 于 片 键 值 数 量 有 限 ， 因 此 这 种 片 键 称 为 小 基数 片 键 (low-cardinality shard key). 
如 果 选 择 了 一 个 基数 很 小 的 片 键 ， 到 头 来 肯定 会 得 到 一 堆 既 巨大 又 无 法 移动 ， 还 不 
能 分 割 的 块 ， 它 们 会 让 你 极为 不 快 ， 这 样 的 生活 你 懂 的 。 

如 果 这 么 做 是 为 了 手动 分 配 数据 ， 那 就 不 要 再 用 MongoDB 内 置 的 分 片 机 制 了 ， 否 
则 它 会 和 你 一 直 抗 争 到 底 。 当 然 ， 不 管 怎样 你 还 是 可 以 手动 对 集合 进行 分 片 ， 编 写 
自己 的 路 由 器 ， 并 将 读 写 路 由 到 任何 一 台 (A) 服务 器 上 。 只 不 过 选择 一 个 好 片 键 
并 让 MongoDB 来 替 你 做 这 一 切 更 容易 一 些 。 


1. 适用 的 键 

这 个 规则 适用 于 任何 取 值 个 数 有 限 的 键 。 一 定 要 记得 ， 如 果 在 某 集 合 中 一 个 键 有 入 
个 值 ， 那 就 只 能 有 V 个 数据 块 ， 因 此 也 只 能 及 个 分 片 。 

如 果 打 算 采 用 小 基数 片 键 的 原因 是 需要 在 那个 字段 上 进行 大 量 查询 ， 请 使 用 组 
合 片 键 (一 个 片 键 包 含 两 个 字段 )， 并 确保 第 二 个 字段 有 非常 多 不 同 的 值 可 以 供 
MongoDB 用 来 进行 分 割 。 


2. 例外 


如 果 一 个 集合 有 生命 周期 〈 例 如 ， 每 周 都 创建 一 个 新 的 集合 而 且 你 知道 ， 在 一 周 时 
间 里 数据 量 不 会 接近 任何 分 片 的 最 大 容量 )， 就 可 以 选择 这 个 生命 周期 为 片 键 。 
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3. 数据 中 心 感知 

这 个 例子 不 仅仅 是 关于 选择 小 基数 片 键 的 ， 还 与 在 MongoDB 分 片 机 制 中 添加 数据 
中 心 感知 (data-center awareness) 支持 的 尝试 有 关 。 到 目前 为 止 , 分 片 尚 不 支持 数 
据 中 心 感 知 。 如 果 对 此 感 兴 趣 ， 可 以 查看 或 对 相关 的 问题 投票 。" 


靠 使 用 者 自己 实现 的 问题 在 于 其 扩展 性 并 不 是 很 好 。 如 果 你 的 应 用 最 近 在 日 本 很 流 
行 怎么 办 ?你 可 能 会 想 添 加 第 二 个 分 片 来 应 付 亚 洲 地 区 的 访问 量 。 


但 是 你 打算 如 何 迁 移 数据 呢 ? 一 个 数据 块 增 长 到 好 几 GB 大 ， 你 就 设法 移动 它 了 ， 
而 且 也 不 能 再 分 割 块 ， 因 为 整个 块 就 只 有 一 个 片 键 值 。 由 于 片 键 值 无 法 更 新 ， 因 此 
也 不 可 能 通过 更 新 所 有 文档 来 使 用 一 个 更 独特 的 片 键 值 。 可 以 删除 每 个 文档 ， 更 新 
片 键 值 ， 然 后 再 把 它 重新 保存 回去 ， 但 是 对 于 大 型 数据 库 而 言 那 并 不 是 一 个 能 迅速 
完成 的 操作 。 


你 所 能 做 的 最 好 的 事情 就 是 在 插入 文档 时 开始 用 "Asia, Japan" 替代 简单 的 
"Asia", 这 样 一 来 会 有 一 批 旧 文档 ， 其 片 键 值 应 该 是 "Asia,Japan" 但 却 是 
"asia"， 因 此 应 用 程序 逻辑 就 不 得 不 同时 支持 两 种 情况 。 另 外 ， 一 旦 开始 拥有 更 细 
粒度 的 块 ， 就 不 能 保证 MongoDB 还 会 把 它们 放 在 你 所 期 望 的 地 方 〈 除 非 关 闭 平衡 
器 并 手动 处 理 所 有 事情 ) o 


数据 中 心 感知 对 于 大 型 应 用 非常 重要 ， 而 且 它 对 MongoDB 的 开发 者 有 很 高 的 优先 
级 。 在 这 期 间 选 择 一 个 小 基数 片 键 绝 不 会 是 一 个 好 的 解决 方案 。 


3.12 FARA 

从 RAM 中 读 取 数据 要 比 从 磁盘 中 读 取 快 ， 所 以 目标 是 尽 可 能 多 地 访问 内 存 中 的 数据 。 
因此 ， 如 果 有 些 数据 总 是 被 一 起 访问 ， 我 们 就 希望 厂 键 能 够 把 它们 保持 到 一 起 。 对 大 
部 分 应 用 程序 而 言 ， 新 数据 被 访问 的 次 数 总 比 老 数据 多 ， 所 以 人 们 往往 会 尝试 使 用 诸 
如 时 间 改 或 者 objectId 一 类 的 字段 来 做 片 键 。 但 是 这 并 不 像 他 们 所 期 望 的 那样 可 行 。 


比方 说 我 们 有 一 个 类 似 微 博 的 服务 ， 其 中 每 个 文档 都 包含 一 条 短 消 息 、 发 送 人 以 及 
发 送 时 间 。 我 们 按 发 送 时 间 字 段 来 分 片 ， 取 值 为 自 公 元 元 年 起 经 过 的 秒 数 。 


和 往常 一 样 ， 还 是 从 一 个 数据 块 (Co, o) 开始 。 全 部 插入 都 会 落 到 这 个 分 片上 
直至 它 分 裂 成 两 个 块 ， 比 如 说 (- © ,1294516901) 和 [1294516901，ce ) 。 由 于 是 
从 片 键 中 点 把 块 分 开 来 的 ， 所 以 在 我 们 分 割 块 的 那 一 刻 ， 时 间 蕉 很 可 能 已 经 远大 于 
1294516901。 这 意味 着 再 往 后 所 有 的 插入 都 会 落 到 第 二 个 块 上 ， 不 会 再 有 插入 操作 


译注 1: 2.0 版 本 已 发 生变 化 ， 详 情 见 http:/www.mongodb.org/display/DOCS/2.0+Release+Notes#2.0ReleaseNotes- 


Datacenterawareness。 
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命中 第 一 个 块 。 一 旦 第 二 个 块 填 满 了 ， 它 就 会 分 裂 成 [1294516901,1294930163) 和 
[1294930163, co) 两 个 块 。 但 是 因为 从 现在 起 时 间 都 在 1294930163 之 后 ， 所 以 新 
的 插入 都 会 被 添加 到 区 间 为 [1294930163, ©) 的 块 上 。 这 个 模式 会 持续 下 去 : 所 有 
数据 总 是 被 添加 到 “最 后 ”一 个 数据 块 上 ， 即 所 有 数据 都 会 被 添加 到 一 个 分 片上 。 


这 个 片 键 创造 了 一 个 单一 且 不 可 分 散 的 热点 。 





1. 适用 的 键 
这 条 规则 适用 于 任何 升序 排列 的 键 值 ， 而 并 不 必须 是 时 间 戳 。 其 他 例子 包括 Object Id, 
日 期 、 自 增 主键 〈 很 可 能 是 从 其 他 数据 库 导 入 的 ) 。 只 要 键 值 趋向 于 无 穷 大 ， 你 就 会 


面临 这 个 问题 。 





2. 例外 

基本 上 ， 这 种 片 键 总 是 一 个 坏 主意 ， 因 为 它 导 致 热点 必然 存在 。 如 果 访 问 量 不 大 且 
用 一 个 分 片 就 能 承受 所 有 读 写 ， 那 还 行 得 通 。 当 然 ， 如 果 遇 到 一 个 访问 量 尖 峰 或 者 
应 用 开始 变 得 更 受 欢迎 ， 那 它 终 会 停止 工作 并 且 难 以 修复 。 


除非 你 非常 清楚 自己 在 干什么 ， 否 则 不 要 使 用 升序 片 键 。 肯 定 还 有 更 好 的 片 键 存在 ， 
应 该 避免 使 用 这 一 个 。 


3.1.3 ”随机 片 键 
有 时 为 了 避免 热点 ， 人 们 会 选择 一 个 取 值 随机 的 字段 来 分 片 。 采 用 这 种 片 键 一 开始 
还 不 错 ， 但 是 随 着 数据 量 越 变 越 大 ， 它 会 变 得 越 来 越 慢 。 


假设 我 们 在 分 片 集合 中 存储 照片 的 缩 略 图 。 每 个 文档 都 包含 了 照片 的 二 进 制 数据 、 
二 进 制 数据 的 MDS 散 列 值 ， 以 及 一 段 描述 、 拍 照 时 间 和 拍照 人 。 我 们 决定 在 MDS 
散 列 值 上 做 分 片 。 


随 着 集合 的 增长 ， 我 们 最 终 会 得 到 一 组 均匀 分 布 于 各 分 片 的 数据 块 。 目 前 为 止 一 切 
顺利 。 现 在 ,假设 我 们 非常 忙 而 分 片 2 上 的 一 个 块 填 满 并 分 裂 了 。 配 置 服务 器 注意 
到 分 片 2 比分 片 1 多 出 了 10 个 块 并 判定 应 该 抹 平 分 片 间 的 差距 。 这 样 MongoDB 就 
需要 随机 加 载 5 个 块 的 数据 到 内 存 中 并 将 其 发 送 给 分 片 1。 考 虑 到 数据 序列 的 随机 
性 ,一般 情况 下 这 些 数据 可 能 不 会 出 现在 内 存 中 。 所 以 此 时 的 MongoDB 会 给 RAM 
带 来 更 大 压力 ， 而 且 还 会 引发 大 量 磁盘 IO (磁盘 IO 总 是 非常 慢 )。 

除 此 以 外 ， 片 键 上 必须 有 索引 ， 因 此 如 果 选 择 了 从 不 依据 它 进行 查询 的 随机 键 ， 基 
本 上 可 以 说 是 “浪费 ”了 一 个 索引 。 另 外 ， 考 虑 到 每 增加 一 个 索引 都 会 让 写 操作 变 
得 更 慢 ， 所 以 保持 索引 数量 尽 可 能 低 也 是 非常 重要 的 。 
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3.1.4 好 片 键 

我 们 真正 需要 的 是 一 种 将 访问 模式 也 考虑 进去 的 方案 。 如 果 应 用 会 规律 性 地 访问 25 
GB 的 数据 ， 我 们 就 希望 所 有 的 分 割 和 迁移 都 发 生 在 这 25 GB 数据 上 ， 而 不 是 随机 
访问 数据 以 至 于 不 断 地 有 新 数据 被 从 磁盘 中 复制 到 内 存 里 


因此 我 们 希望 能 找到 这 样 一 个 片 键 ， 它 具备 有 良好 的 数据 局 部 性 〈data locality) 特 
征 ， 但 又 不 会 因 太 局 部 而 导致 热点 出 现 。 





1. 准 升序 键 加 搜索 键 
许多 应 用 访问 新 数据 比 老 数据 更 频 蛇 ， 所 以 我 们 希望 数据 大 臻 上 按照 时 间 排 序 ， 但 
是 同时 也 要 均匀 分 布 。 这 样 一 来 既 能 把 我 们 正在 读 写 的 数据 保持 在 内 存 中 ， 又 可 以 
使 负载 均衡 地 分 散在 集群 中 。 


我 们 可 以 通过 像 {coarselyAscending:1,search:1} 这 样 的 组 合 片 键 (compound 
shard key) 来 实现 目标 。 其 中 coarselyAscending 键 的 每 个 值 最 好 能 对 应 几 十 到 
几 百 个 数据 块 ， 而 search 键 则 应 当 是 应 用 程序 通常 都 会 依据 其 进行 查询 的 字段 。 


举 个 例子 ， 比 如 说 有 个 分 析 程 序 ， 用 户 会 定期 通过 它 访 问 过 去 一 个 月 的 数据 ， 而 我 
们 希望 能 尽量 保持 数据 易于 使 用 。 因 此 可 以 在 {month:1,user:1) 上 分 片 ， 其 中 
month 是 一 个 粗 粒 度 的 升序 字段 ， 即 每 个 月 它 都 会 有 一 个 更 新 更 大 的 值 。user 适 
合作 为 第 二 个 字段 ， 因 为 我 们 会 经 常 查询 某 个 特定 用 户 的 数据 。 


还 是 从 一 个 数据 块 开始 ， 组 合 区 间 是 e,- ) ,，(c, co))。 当 它 被 填 满 ， 
我 们 将 其 分 为 两 个 块 ， 比 如 区 间 (C ce, - oo) ，("2011-04","susan")) 和 
[ ("2011-04","susan") ，(co , %))。 假设 现在 还 是 4 Af? ("2011-04"), MA 
有 的 写 操作 都 会 被 均匀 地 分 到 两 个 数据 块 上 。 所 有 用 户 名 小 于 "susan" 的 用 户 都 会 
被 放 在 第 一 个 块 上 ， 而 所 有 用 户 名 大 于 "susan" 的 用 户 都 会 被 放 在 第 二 个 块 上 。 


随 着 数据 持续 增长 ， 这 个 方案 还 会 继续 有 效 。4 月 里 后 续 创 建 的 块 都 会 被 移动 到 不 
同 的 分 片上 ， 从 而 确保 了 读 写 在 集群 中 的 负载 均衡 。 等 5 月 到 来 时 ， 我 们 开始 创建 
边界 为 "2011-05" 的 块 。 随 着 6 月 悄然 而 至 ，"2011-04" 的 数据 块 已 然 无 人 问津 ， 
所 以 就 可 以 将 这 些 块 安静 地 换 出 内 存 使 之 不 再 占用 资源 。 尽 管 以 后 仍 有 可 能 因为 历 
史 原 因 再 查看 这 些 块 ， 但 是 应 该 不 需要 再 分 割 或 迁移 它们 了 (使 用 随机 索引 难以 名 
免 的 问题 )。 



































为 什么 不 将 {ascendingKey : 1} 用 作 片 键 ? 
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在 3.1.2 节 提 到 过 ， 如 果 你 把 它 和 一 个 粗 粒度 的 升序 键 合 在 一 起 用 ， 还 是 会 创造 出 
一 扒 巨 大 且 无 法 分 割 的 数据 块 。 











search 字段 可 不 可 以 也 是 升序 字段 ? 


不 可 以 。 如 果 是 ， 则 该 片 键 会 降级 成 一 个 升序 片 键 ， 进 而 使 你 同样 面临 普通 升序 键 
带 来 的 热点 问题 。 





search 字段 应 该 是 什么 ? 


search 字段 最 好 是 应 用 程序 可 以 用 于 查询 的 东西 ， 比 如 用 户 信息 〈 比 如 上 面 的 例 
子 )、 文 件 名 字段 或 者 GUID 等 。 它 应 该 具备 非 升序 、 分 布 随机 且 基 数 适当 的 特点 。 


3. 一 般 情 况 
基于 上 面 的 内 容 ， 我 们 可 以 概括 出 一 个 片 键 公式 : 
{coarseLocality : 1,search : 1} 


其 中 coarseLocality 字段 用 来 控制 数据 局 部 化 。search 字段 则 是 数据 上 常用 到 
的 一 个 检索 字段 。 


这 个 键 并 不 是 唯一 可 能 的 片 键 ， 也 不 会 在 任何 情况 下 都 有 效 。 尽 管 如 此 ， 即 便 你 最 
终 并 不 使 用 它 ， 但 就 启发 思 芳 如 何 选择 片 键 而 言 ， 这 仍 是 一 个 好 的 开始 。 


4. 我 该 用 哪 种 片 键 
真 的 没 办 法 告诉 你 ， 因 为 我 并 不 了 解 你 的 应 用 程序 。 不 过 选择 一 个 好 的 片 键 应 该 会 
花费 一 些 功 夫 。 在 选 定 一 个 片 键 之 前 ， 不 妨 先 想 想 下 面 这 些 问题 的 答案 。 


。 写 操 作 是 怎样 的 ?你 要 插入 什么 文档 ， 有 多 大 ? 
。 系统 每 小 时 会 写 多 少数 据 ? 每 天 呢 ? 高 峰 期 呢 ? 
。 哪些 字段 取 值 是 随机 的 ， 哪 些 是 增长 的 ? 

。 读 操 作 是 怎样 的 ?” 人 们 在 访问 哪些 数据 ? 

。 系统 每 小 时 会 读 多 少数 据 ? 每 天 呢 ? 高 峰 期 呢 ? 
。 数据 做 索引 了 吗 ? 应 不 应 该 索引 呢 ? 

。 数据 总 量 有 多 少 ? 


也 许 你 还 会 在 数据 中 发 现 其 他 一 些 模式 ， 那 就 利用 起 来 ! 在 进行 分 片 之 前 ， 你 需要 
清楚 地 了 解 你 的 数据 。 























3.2 ”新 老 集合 分 片 


一 旦 选择 好 片 键 ， 就 可 以 进行 数据 分 片 了 。 


321 快速 起 步 

如 果 想 尽快 建立 起 一 个 集群 玩 玩 看 ， 用 Github 上 的 mongo-snippets 只 要 一 两 分 钟 
就 能 建 好 一 个 。 它 的 文 要 有 点 少 ， 但 是 这 个 库 基 本 上 就 是 一 组 对 用 户 非常 有 用 的 脚 
本 。 甚 中 特别 有 趣 的 一 个 是 simple-setup.py， 它 能 自动 地 启动 、 配 置 和 生成 一 个 集 
群 (本 地 的 )。 


要 运行 这 个 脚本 ， 需 要 MongoDB 的 Python 驱动 。 如 果 没 有 ， 可 以 通过 执行 下 面 的 
语句 来 安装 (在 *NIX 系统 上 ) : 








$ sudo easy install pymongo 
一 旦 Pymongo 装 好 了 ， 下 载 mongo-snippets 库 并 执行 下 面 的 命令 : 
$ python sharding/simple-setup.py --path=/path/to/your/mongodb/binaries 


这 里 有 很 多 其 他 可 用 的 选项 ， 执 行 python sharding/simple-setup.py-help 
可 查阅 它们 。 这 个 脚本 有 点 挑剔 ， 所 以 请 确保 使 用 完全 路 径 〈 例 如 /home/user/ 
mongo-install， 而 非 ~/nongo-install) 。 

simple-setup.py 会 启动 一 个 mongos 进程 ， 地 址 为 localhost:27017， 这 样 就 可 以 用 
shell 命令 连 上 它 来 使 用 了 。 

如 果 想 建立 一 个 企业 级 集群 ， 请 继续 读 下 去 。 


3.2.2 ”配置 服务 器 
你 可 以 运行 1 个 或 3 个 配置 服务 器 。 我 们 会 采用 3 个 配置 服务 器 ， 在 生产 环境 里 任 
何 时 候 都 应 当 这 么 做 。 


“1 个 或 3 个 ”是 个 奇怪 且 有 些 专 断 的 限制 ， 原因 是 1 个 适 于 测试 环境 ， 而 
WS a 3 个 适 于 生产 环境 。2 个 对 测试 环境 来 说 多 了 ， 对 生产 环境 来 说 又 不 够 。 
不 能 运行 任意 个 数 的 配置 服务 器 ， 因 为 它们 之 间 的 交互 是 复杂 的 ， 而 
目 M 个 配置 服务 器 中 停 掉 YX 个 时 的 处 理 逻 辑 和 编程 都 非常 困难 。 将 来 
MongoDB 可 能 会 支持 任意 个 数 的 配置 服务 器 ， 但 这 并 不 是 当务之急 。 















































设置 配置 服务 器 很 乏味 ， 因 为 它们 只 是 普通 的 mongod 实例 。 设 置 时 唯一 要 注意 的 
是 ， 由 于 需要 它们 中 的 部 分 配置 服务 器 一 直 正 常 运行 ， 所 以 应 尽 可 能 把 它们 分 到 不 
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同 的 故障 域 (failure domain) 里 。 


比方 说 我 们 有 3 个 数据 中 心 ， 一 个 在 纽约 ， 一 个 在 旧金山 ， 还 有 一 个 在 月 球 上 。 此 
时 只 需 每 个 数据 中 心 启 动 一 个 配置 服务 器 。 


$ ssh ny-01 
ny-01$ mongod 


$ ssh sf-01 
sf-01$ mongod 


$ ssh moon-01 
moon-01$ mongod 


就 这 么 简单 ! 
你 可 能 会 从 上 面 的 设置 中 发 现 一 个 小 问题 。 这 些 本 应 联系 密切 的 服务 器 并 不 知道 其 


他 服务 器 的 存在 抑或 知道 它们 扮演 着 配置 服务 器 的 角色 。 没 有 问题 一 一 接 下 来 我 们 
会 介绍 它们 相互 认识 。 





有 时 人 们 认为 必须 在 配置 服务 器 上 设置 复制 。 实 际 上 配置 服务 器 并 不 使 用 
ED “普通 ”mongod 所 采用 的 复制 机 制 ， 而 且 也 不 应 该 按 副本 集 或 主 从 设置 启 
动 。 只 要 把 配置 服务 器 当做 未 连接 的 普通 mongod 启动 就 行 了 。 















































当 你 启动 配置 服务 器 时 ， 运 行 mongod -help 的 输出 中 “General Option” 下 面 的 
选项 可 以 随意 使 用 , 但 --keyFile 和 --auth 除外 。 分 片 现在 还 不 支持 认证 ， 但 在 
BGA 1.9 版 的 半路 上 这 应 该 有 所 改变 。" 


带 --quiet 参数 运行 可 不 是 一 个 好 主意 ， 因 为 如 果 出 了 问题 就 需要 能 弄 清 楚 发 生 了 
什么 。 可 以 用 --logpath <file> 和 --logappend 来 代替 --quiet 将 日 志 发 送 
到 某 处 ， 这 样 如 果 出 问题 ， 就 有 日 志 可 以 回 渊 。 


Sharding (分 片 ) 选项 适用 于 分 片 ， 而 非 配置 服务 器 ， 所 以 可 以 忽略 它们 。 你 也 不 
需要 其 他 (Replication, Replica set 或 者 Master/slave 下 面 的 ) 选项 ， 因 为 你 不 会 在 
配置 服务 器 上 启用 复制 机 制 ， 对 吧 ? 




















3.2.3 mongos 


接 下 来 是 启动 mongos 进程 。 一 个 分 片 配置 需要 至 少 一 个 mongos, 但 无 上 限 。 要 记 
住 必 须 (至 少 应 该 ) 监视 所 有 mongos 进程 ， 因 此 你 很 可 能 不 会 想 启动 数 千 个 进程 ， 








译注 1: 2.0 版 本 已 发 生变 化 ， 详 情 风 http://www.mongodb.org/display/DOCS/2.0+Release+Notes#2.0ReleaseNotes- 
ShardingAuthentication。 
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一 般 来 说 每 个 应 用 程序 服务 器 一 个 mongos 进程 就 挺 好 。 接 下 来 我 们 登录 应 用 程序 
服务 器 并 启动 第 一 个 mongos。 


$ ssh ny-02 
ny-01$ mongos --configdb ny-01,sf-01,moon-01 


按 下 回 车 ,现在 所 有 配置 服务 器 都 知道 其 他 配置 服务 器 了 。mongos 就 像 派 对 上 的 主 
人 ， 会 介绍 宾客 们 相互 认识 。 


现在 你 有 了 一 个 微型 集群 。 尽 管 还 不 能 存 任何 数据 进去 (配置 服务 器 只 存 配置 不 存 
数据 )， 但 是 除 此 以 外 ， 它 完全 可 以 正常 工作 。 


你 可 能 想 用 数据 库 读 写 数据 ， 所 以 让 我 们 添 一 些 数据 存储 机 制 进来 。 
3.2.4 分 片 


集群 上 的 所 有 管理 工作 都 是 通过 mongos 完成 的 。 所 以 ， 先 用 shell 命令 连 上 之 前 启 
动 的 mongos。 





$ mongo ny-02:27017/admin 
MongoDB shell version: 1.7.5 
connecting to: admin 

od 


确认 当前 使 用 的 是 admin 数据 库 ， 设 置 分 片 需要 在 admin 数据 库 中 执行 命令 。 


一 旦 连 上 ， 就 可 以 添加 分 片 了 。 添 加 分 片 有 两 种 方法 ,使 用 哪 种 取决 于 分 片 是 
单个 服务 器 还 是 副本 集 。 假 设 我 们 有 一 个 服务 器 sf-02， 一 直 用 来 放 数 据 。 执 行 


addshard 命令 我 们 可 以 让 它 成 为 第 一 个 分 片 : 

> db.runCommand({"addShard" : "sf-02:27017"}) 

{ "shardAdded" : "shard0000", "ok" : 1 } 
这 个 命令 将 服务 器 添加 到 集群 中 。 现 在 可 以 存储 和 查询 数据 了 。 (如果 存储 数据 时 还 
不 存在 任何 可 以 用 于 存储 数据 的 分 片 ，MongoDB 会 提示 错误 ， 理 由 不 言 自 明 。) 


通常 情况 下 ， 应 该 用 副本 集 (而 非 单个 服务 器 ) 来 做 每 个 分 片 。 副 本 集 能 提供 更 好 
的 可 用 性 。 要 添 一 个 副本 集 分 片 ， 必 须 传 给 命令 addshard 一 个 形 如 "setName/ 
seed1l[,seed2[,seed3[,...]]]" 的 字符 串 ， 即 必须 提供 副本 集 的 名 称 和 至 少 一 
个 集合 成 员 (mongos 可 以 推出 其 他 成 员 ， 前 提 是 它 能 连 上 它们 中 任意 一 个 ) 。 


举 个 例子 ， 如 果 我 们 有 个 副本 和 集 叫做 rs， 其 成 员 为 rs1-a、rs1-b 和 rs1-c。 我 们 可 以 
执行 : 
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> db.runCommand({"addShard" : "rs/rsl-a,rsl-c"}) 
{ "shardAdded" : "rs", "ok" : 1 } 


注意 ， 这 一 次 得 到 的 名 称 漂亮 多 了 ! (我 就 是 那个 写 程序 让 它 挑 出 副本 集 名 称 的 人 ， 
所 以 对 这 点 感到 特别 自豪 。) 如 果 添 加 一 个 副本 集 ， 则 它 的 名 称 会 成 为 分 片 的 名 称 。 











Ha 
is 可 以 随意 命名 分 片 。 如 果 不 想 使 用 默认 值 ， 就 在 添加 分 片 时 加 上 name 字段 。 
ae 
ww A > db.runCommand({"addShard" : "sf-02:27017", "name" : 
as "Golden Gate shard"}) 
{ "shardAdded" : "Golden Gate shard", "ok" : 1 } 
> db. runCommand ({"addShard" : "setl/rsl-a,rsl-b", "name" 
"replicaSet1"}) 
{ "shardAdded" : "replicaSet1", "ok" : 1 } 
某 些 场合 下 你 将 不 得 不 使 用 名 字 来 引用 分 片 〈 见 第 5 章 ) ， 所 以 别 把 名 字 定 
得 太 长 太 疯 狂 。 
限制 分 片 大 小 








默认 情况 下 ，MongoDB 会 在 分 乒 间 均匀 地 分 配 数据 。 如 果 使 用 的 是 一 组 通用 配置 
服务 器 ， 那 这 就 很 有 用 ， 但 如 果 有 一 个 台 10 TB 的 剩 悍 机 器 ， 而 另 一 台 是 就 儿 百 
GB 的 普通 机 器 ， 那 就 有 问题 了 。 如 果 服 务 器 失衡 严重 ， 应 该 使 用 maxsize 选项 ， 
它 可 以 用 来 指定 分 片 能 增长 到 的 最 大 存储 量 ， 单 位 MB. 


























要 记 住 maxSize 更 像 是 一 个 建议 而 非 规定 。MongoDB 不 会 从 maxSize 处 截断 一 个 
分 片 ， 或 是 阻止 它 再 增加 哪怕 一 个 字 节 ， 而 是 会 停止 将 数据 移动 到 该 分 片 ， 当 然 还 
可 能 会 挪 走 一 部 分 数据 ， 如 果 它 觉得 这 么 做 合适 的 话 。 所 以 设置 这 个 值 时 可 以 略微 
R=, 
maxSize 是 addShard 命令 的 又 一 个 选项 ， 如 果 想 要 设置 一 个 分 片 只 使 用 20 GB, 
可 以 执行 : 

> db.runCommand ({"addShard" : "sfo/serverl,server2", "maxSize" : 20000}) 
将 来 ，MongoDB 会 自动 分 析出 在 每 个 分 片上 可 以 配置 多 少 空 间 并 相应 地 做 计划 。 
在 此 期 间 ， 你 可 以 使 用 maxsize 给 它 一 个 提示 。 


现在 你 终于 有 了 一 个 全 副 武装 且 可 以 运行 的 集群 ! 


3.2.5 ”数据库 和 集合 
如 果 想 要 MongoDB 来 帮 你 分 配 数据 ， 就 要 让 它 知道 具体 需要 处 理 的 数据 库 和 集合 。 
在 尝试 对 一 个 数据 库 中 的 集合 进行 分 片 前 ， 你 必须 先 告诉 MongoDB 该 数据 库 可 以 
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包含 分 片 集合 。 


假设 我 们 在 写 一 个 博客 程序 ， 所 有 集合 都 在 blog 数据 库 中 。 我 们 可 以 用 如 下 命令 来 
启用 分 片 : 








> db.adminCommand({"enableSharding" : "blog"}) 
{ "ok" : 1 } 


现在 就 可 以 对 集合 进行 分 片 了 。 要 进行 分 片 必须 指定 集合 和 片 键 。 假 设 我 们 在 
{"date" : 1,"author" : 1} ESF: 


> db .adminCommand({"shardCollection" : "blog.posts", key : {"date" ae ee 
"author" : 1}} 
{ "collectionSharded" : "blog.posts", "ok" : 1 } 


注意 ， 命 令 里 包含 了 数据 库 名 blogposts, MIE posts. 


如 果 要 对 一 个 已 经 包含 数据 的 集合 进行 分 片 ， 数 据 片 键 上 必须 有 索引 。 所 有 文档 也 
都 必须 有 片 键 值 ( 且 值 不 能 为 nul1)。 在 集合 分 片 完 成 后 ， 才 可 以 插入 片 键 值 为 
null 的 文档 。 





3.3 ERAS 

随 着 应 用 持续 增长 ， 你 需要 添加 更 多 的 分 片 。 添 完 新 分 片 以 后 ，MongoDB 就 会 从 
老 分 片 向 新 分 片 移动 数据 。 注 意 ， 数 据 移 则 压力 增 。 当 然 ，MongoDB 会 尽 可 能 轻 
柔 地 迁移 数据 ， 它 会 每 次 一 个 块 地 慢 慢 移动 数据 ， 如 果 服 务 器 看 起 来 很 忙 就 等 会 儿 
再 试 。 尽 管 如 此 ， 无 论 MongoDB 多 么 轻巧 地 操作 ， 移 动 数据 块 仍然 会 加 重负 载 。 


这 意味 着 如 果 等 服务 器 容量 耗 尽 再 添加 分 片 ， 添 加 新 分 片 可 能 会 导致 应 用 程序 在 一 系 
列 连锁 反应 下 逐步 瘫痪 。 假 设 现 有 分 片 就 快要 达到 最 大 容量 了 ， 所 以 你 添 一 个 新 分 片 
进来 帮助 处 理 负载 。 平 衡器 会 告诉 分 片 1 给 新 分 片 发 送 一 个 数据 块 。 分 片 1 的 内 存 刚 
刚 够 容 下 应 用 程序 运行 时 数据 ， 而 现在 它 将 不 得 不 把 一 整个 数据 块 加 载 进 内 存 。 为 了 
给 新 加 载 的 块 腾 出 足够 空间 ， 应 用 程序 所 使 用 的 数据 开始 被 换 出 RAM。 这 意味 着 应 
用 程序 不 得 不 开始 访问 磁盘 ， 而 MongoDB 正在 为 那 块 被 加 载 的 数据 访问 磁盘 。 查 
询 耗 时 开始 延长 ， 请 求 也 逐渐 排 起 长 队 ， 这 进一步 导致 了 问题 恶化 ( 见 图 3-2)。 


学 到 的 教训 是 什么 ”要 在 还 有 足够 空间 做 调度 时 添加 分 片 。 如 果 已 经 没有 那么 多 空 
间 了 ， 就 等 到 半夜 三 更 (或 者 另外 一 个 非 忙 时 段 ) 再 添加 分 片 。 如 有 果 没 有 非 忙 时 段 ， 
而 且 已 经 等 了 太 长 时 间 ， 还 有 一 些 办 法 来 破解 困 局 ， 但 是 这 些 方法 既 不 有 趣 也 不 容 
易 。( 可 以 用 现存 备份 让 分 片 借 尸 还 瑰 ， 然 后 手动 更 改 config.chunks 集合 ， 再 重 局 
整个 集群 ， 但 很 明显 这 种 做 法 并 不 被 提倡 。) 所 以 添加 分 片 要 尽早 做 ,经常 做 。 
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B 3-2: 移动 块 会 迫使 数据 被 换 出 RAM ， 导 致 更 多 请 求 命中 磁盘 并 拖 慢 整个 系统 





那么 再 回想 一 下 ， 如 何 添加 分 片 呢 ? 方法 和 前 面 添加 第 一 个 分 片 是 一 样 的 ， 用 
addShard 命令 。 


之 后 再 添加 分 片 有 一 点 很 有 意思 ， 即 分 片 不 必 是 空 的 。 分 片 不 能 包含 集群 中 已 有 的 
数据 库 ， 但 是 如 果 集 群星 有 一 个 foo 数据 库 ， 而 新 添加 的 分 片 里 包含 bar 数据 库 ， 
那么 不 会 产生 任何 问题 ， 因 为 配置 服务 器 会 注意 到 它 ， 而 它 会 出 现在 集群 信息 中 。 
因此 ， 如 果 你 愿意 ， 可 以 把 多 个 不 同 的 系统 集中 起 来 攒 出 一 个 大 号 的 分 片 集群 。 


3.3.1 移 除 分 片 

有 了 时 也 需要 移 除 分 片 。 某 些 人 可 能 过 早 地 进行 了 分 片 或 者 选 错 了 片 键 ， 所 以 想 把 所 
有 东西 都 放 回 到 一 个 分 片上 ， 然 后 转 储 ， 然 后 恢复 ， 然 后 重新 来 过 。 你 可 能 只 是 想 
让 某 些 服务 器 下 线 。 


removeShard 命令 可 以 用 于 从 集群 中 摘除 分 片 。 
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> db.runCommand({removeShard : "Golden Gate shard"}) 


{ 


"msg" : "draining started successfully", 
"State" : "started", 

"shard" : "Golden Gate shard", 

Tok" + ł 


} 


注意 ， 消 息 是 说 “started successfully” (已 启动 成 功 ) 。 在 移 除 一 个 分 片 前 需要 把 分 
片上 的 所 有 信息 都 转移 到 其 他 分 片上 。 正 如 前 面 提 到 的 ， 在 分 片 间 挪动 数据 非常 耗 
Ih}, removeShard 命令 会 立即 返回 ， 你 必须 通过 轮 询 了 解 操作 是 否 已 经 完成 。 如 果 
再 调用 一 次 ， 就 会 看 到 像 这 样 的 消息 


> db.runCommand({removeShard : "Golden Gate shard"}) 


{ 
"msg" : "draining ongoing", 
"State" : "ongoing", 
"remaining" : { 
"chunks" : NumberLong(2), 
"dbs" : NumberLong (1) 


"ok" : 1 
} 


一 旦 完成 ， 其 状态 会 变 成 “completed”。 那 之 后 ， 就 可 以 安全 地 关闭 分 片 了 (或 者 
把 它 当 做 一 个 未 分 片 的 MongoDB 服务 器 来 用 )。 


> db.runCommand({removeShard : "Golden Gate shard"}) 


{ 

"msg" : "removeshard completed successfully", 
"State" : "completed", 

"shard" : "Golden Gate shard", 

"ok" 1 


这 意味 着 分 片 已 经 完全 清空 并 可 以 关机 或 挪 做 它 用 了 。 


3.3.2 ”修改 分 片 中 的 服务 器 

如 果 使 用 了 副本 集 ， 可 以 添加 或 删除 副本 集中 的 服务 器 ， 而 mongos 会 注意 到 这 些 
aie 要 修改 革 个 集群 中 的 副本 集 ， 就 假定 它 是 独立 运行 的 来 进行 : 连接 主 服务 器 
(而 非 通过 mongos) 并 修改 相应 配置 。 
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使 用 集群 


查询 MongoDB 集群 通常 和 查询 mongod 是 一 样 的 。 尽 管 如 此 ， 还 是 有 些 例外 情况 
值得 了 解 一 下 。 


4.1 查询 

如 果 使 用 副本 集 且 mongos 为 1.7.4 或 更 高 版 本 ， 你 可 以 把 读 分 散 到 集群 的 从 机 
上 。 这 样 就 能 很 轻松 地 处 理 读 负载 ， 当 然 CAP 原则 也 会 应 验 : 你 必须 要 接受 过 时 
的 数据 。 

要 通过 mongos 查询 一 台 从 机 ， 无 论 使 用 哪 种 驱动 都 必须 设置 “slave okay” 选 项 
(基本 上 就 是 确认 接受 有 可 能 过 期 的 数据 )。 在 shell 里 ， 看 起 来 就 像 这 样 : 

















> db.getMongo() .setSlaveOk () 


接着 正常 查询 mongos 即 可 。 


4.2 为 什么 会 这 样 

使 用 集群 时 ， 就 不 能 把 整个 集合 看 做 是 一 个 “即时 快照 ”(snapshot in time) 了 。 人 很 
多 人 撞 了 南 墙 才 意识 到 这 个 问题 的 严重 性 ， 所 以 让 我 们 来 看 看 这 个 问题 对 应 用 程序 
的 一 些 和 常见 影响 。 








4.2.1 计数 
当 你 在 一 个 分 片 集合 上 进行 计数 (count) 时 ， 可 能 得 不 到 期 望 的 结果 ， 可 能 是 一 个 
比 实际 文档 量 多 得 多 的 数 。 


计数 的 工作 方式 是 通过 mongos 将 count 命令 发 送 给 集群 中 的 每 个 分 片 。 然 后 ， 每 
个 分 片 各 自 执 行 count 并 把 结果 返回 给 mongos, mongos 再 把 结果 累加 起 来 最 后 返 
回 给 用 户 。 如 果 有 一 个 迁移 正在 进行 ， 许多 文档 就 会 同时 存在 (进而 被 纳入 计数 ) 
于 多 个 分 片上 。 


当 MongoDB 迁移 数据 块 时 ， 首 先 将 块 从 一 个 分 片 复制 到 另 一 个 分 片 。 期 间 所 有 对 
该 块 的 读 写 操作 仍然 会 被 路 由 到 原 分 片 , 不 过 块 会 在 另 一 边 的 分 片上 被 逐渐 填充 。 
一 旦 数据 块 “ 移 动 ” 完 成 ， 它 实际 上 存在 于 两 个 分 片 。 最 后 一 步 ， MongoDB AS 
更 新 配置 服务 器 并 删除 原来 分 片上 的 数据 副本 ( 见 图 4-1)。 


因此 ， 当 这 部 分 数据 被 计数 时 ， 实 际 上 被 算 了 两 次 。 将 来 MongoDB 也 许 会 解决 这 
个 问题 ， 但 现在 请 记 住 计数 值 可 能 会 大 于 实际 的 文档 数 。 

















使 用 集群 | 39 





分 片 A 分 片 B 














图 4-1: 通过 复制 将 一 个 块 迁 移 到 新 的 分 片上 ， 然 后 再 从 源 分 片上 将 它 删 除 


4.2.2 ”唯一 索引 
假设 我 们 在 email 字段 上 进行 分 片 ， 同 时 还 想 在 username 字段 上 加 一 个 唯一 索 
引 ， 这 在 集群 中 是 不 可 能 强制 实施 的 。 


比方 说 我 们 有 两 个 应 用 程序 服务 器 负责 处 理 用 户 信息 ， 其 中 一 个 添加 了 包含 如 下 字 
段 的 新 用 户 文档 : 
{ 


"vid" : ObjectId("4d2a2e9f74de15b8306fe7d0"), 
"username" : "andrew", 
"email" : "awesome.guy@example.com" 
} 
要 检查 “andrew” 是 否 为 集群 中 唯一 的 “andrew"， 需 要 遍历 每 一 台 服 务 器 上 每 
个 文档 的 username 字段 。 假 设 MongoDB 遍历 了 所 有 分 片 发 现 没 有 其 他 人 再 叫 
“andrew"， 正 当 它 要 把 文档 写 和 人 分 片 3 时， 第 二 个 应 用 程序 服务 器 发 来 了 下 面 这 个 
要 被 插入 的 文档 : 
{ 


"id" : ObjectId("4d2a2f7c56d1bb09196fe7đqd0"), 





"username" : "andrew", 
"email" : "cool.guy@example.com" 


} 


又 一 次 ， 每 个 分 片 都 要 检查 确认 自己 没有 名 为 “andrew” 的 用 户 。 当 然 还 不 会 有 ， 
因为 第 一 份 文档 还 没有 被 写 入 ， 这 样 分 片 1 继续 并 写 入 了 这 个 文档 。 接 着 分 片 3 终 
于 有 空 完成 第 一 份 文档 的 写 入 。 现 在 就 出 现 两 个 用 户 名 相同 的 人 了 1! 


通常 情况 下 ， 要 确保 分 片 间 不 存在 重复 ， 唯 一 的 方法 是 在 每 次 要 执行 写 操作 时 锁 住 
整个 集群 ， 直 至 写 操作 确认 成 功 。 这 样 做 系统 很 难 实 现 高 性 能 写 。 


因此 ， 除 片 键 以 外 任何 键 都 难以 保证 唯一 性 。 可 以 保证 片 键 的 唯一 性 是 因为 特定 文 
档 只 能 属于 一 个 数据 块 ， 所 以 它 只 需要 在 那个 分 片上 唯一 ， 就 能 保证 在 整个 集群 
中 是 唯一 的 。 你 也 可 以 有 一 个 以 片 键 开头 的 唯一 索引 。 举 个 例子 ， 如 果 我 们 在 用 
户 集合 上 按 username 分 片 ， 和 上 面 一 样 ， 但 是 包含 唯一 性 选项 ， 那 么 就 可 以 在 
{username : 1, email : 1} 上 创建 一 个 唯一 索引 。 


由 此 推出 一 个 有 趣 的 结论 : 除非 在 _ia 上 分 片 ， 否 则 能 够 创建 出 不 唯一 的 _ia 值 。 
尽管 不 推荐 这 么 做 (而且 还 会 在 移动 块 时 带 来 座 烦 )， 但 却 是 可 能 所 






































4.2.3 更 新 

更 新 操作 上 默认 只 针对 单个 记录 。 这 意味 着 它们 和 唯一 索引 面临 同样 的 麻烦 ， 即 没有 
什么 好 办 法 能 确保 操作 在 多 个 分 片 间 只 发 生 一 次 。 因 此 如 果 要 更 新 单个 文档 ,一定 
要 在 条 件 中 使 用 片 键 (update 的 第 一 个 参数 ) 。 如 果 不 这 么 做 ， 你 会 得 到 一 个 
错误 。 








> db.adminCommand({shardCollection : "test.x", key : {"y" : 1}}) 
{ "shardedCollection" : "test.x", "ok" : 1 } 

> 

> // 可 以 运行 

> db.x.update({y : 1}, {$set : {z : 2}}, true) 

> 

> // 出 错 

> db.x.update({z : 2}, {$set : {w : 4}}) 


can't do non-multi update with query that doesn't have the shard key 
批量 更 新 中 可 以 使 用 任何 条 件 。 


> db.x.update({z : 2}, {$set : {w : 4}}, false, true) 
> // 没有 错误 


如 果 碰 到 了 奇怪 的 错误 信息 ， 考 虑 一 下 执行 的 操作 是 否 对 整个 集群 必须 是 原子 化 的 。 
这 类 操作 是 不 被 允许 的 。 





使 用 集群 | 41 


4.3 MapReduce 


在 集群 上 运行 MapReduce 时 ， 每 个 分 片 都 会 执行 它 自己 的 映射 (map) 及 收敛 
(reduce), mongos 选 出 一 个 “领头 羊 ” 分 片 以 接受 来 自 其 他 分 片 的 收敛 结果 并 在 此 
完成 最 后 的 收 伍 。 一 旦 数据 被 收敛 到 最 终 形态 ， 就 会 按照 指定 的 方式 输出 。 


由 于 分 片 将 任务 分 解 到 多 台 机 器 ， 因 此 能 比 单 台 服务 器 更 快 地 执行 MapReduce。 尽 
管 如 此 ， 它 仍 不 适合 做 实时 运算 。 


临时 集合 

1.6 版 里 ， 除 非 声 明了 “out” 参 数 ， 否 则 MapReduce 会 创建 临时 集合 。 这 些 临 时 集 
合 会 一 直 存 在 直至 创建 它们 的 连接 关闭 。 在 单 台 服务 器 上 这 种 工作 方式 运行 得 很 好 ， 
但 是 mongos 会 维护 自己 的 连接 池 而 且 从 不 关闭 对 分 片 的 连接 。 因 此 ， 临 时 集合 永 
远 都 不 会 被 清除 掉 (因为 创建 它们 的 连接 从 未 被 关闭 )， 并 且 它 们 会 一 直 存 在 ， 数 量 


如 果 你 正在 运行 1.6 版 本 同时 还 使 用 了 MapReduce， 就 必须 手动 清理 所 有 临时 集合 。 
在 指定 数据 库 中 ， 你 可 以 通过 执行 下 面 的 函数 来 删除 所 有 临时 集合 : 





























var dropTempCollections = function(dbName) { 
var target = db.getSisterDB(dbName) ; 
var names = target.getCollectionNames() ; 
for (var i = 0; i < names.length; i++) { 


if (names [i] .match(/tmp\.mr\./)) { 
target [names [i]].drop(); 
} 


} 
后 续 版 本 中 ，MapReduce 会 强制 要 求 你 对 输出 进行 处 理 。 详 情 请 查看 文档 。 























译注 1: 1.7.4 及 以 后 版 本 中 ，out 不 再 是 可 选 参 数 ， 其 中 各 种 可 用 的 参数 形式 及 其 含义 具体 见 http://www. 
mongodb. org/display/DOCS/MapReduce。 
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第 5 章 





管理 


上 一 章 主 要 从 应 用 程序 开发 者 角度 来 介绍 使 用 MongoDB 的 有 关内 容 ， 而 本 章 将 更 
多 地 从 运 维 方面 介绍 有 关 集 群 管理 的 内 容 。 集 群 启动 并 运行 起 来 之 后 ， 如 何 了 解 其 
运行 情况 呢 ? 


AAS 
5.1 使 用 命令 行 
对 单个 MongoDB 实例 来 说 ， 对 集群 的 大 部 分 管理 工作 都 可 以 通过 mongo shell 来 


完成 。 





5.1.1 了 解 概 况 


db.printShardingStatus() 可 以 给 出 一 份 执行 概况 。 它 能 收集 所 有 与 集群 有 关 
的 重要 信息 并 漂亮 地 展示 出 来 。 





> db.printShardingStatus () 
--- Sharding Status --- 


sharding version: { "id" : 1, "version" : 3 } 

shards: 

{ "ia" : "shard0000", "host" : "ubuntu:27017" } 

{ "ida" : "shardo001", "host" : "ubuntu:27018" } 

databases: 

{ "id" : "admin", "partitioned" : false, "primary" : "config" } 
{ "id" : "test", "partitioned" : true, "primary" : "shard0000" } 


test.foo chunks: 

shard0001 15 

shard0000 16 

{ "da"; { $minkey : 1} } -->> { "ia" : 0 } on : shardi { "e" : 2, "i" : 0 } 


{ "id" : 0 } -->> { "id" : 15074 } on : shardi. { "e" s 3, "i" : 0 } 

{ "id" : 15074 } -->> { "_id" : 30282 } on: shardl { "t" : 4, "i" : 0 } 
{ "id" : 30282 } -->> { "id" : 44946 } on : shardl { "t" : 5, "i" : 0 } 
{ "id" : 44946 } -->> { "id" : 59467 } on : shardl { "t" : 7, "i" : 0 } 
{ "id" : 59467 } -->> { "_id" : 73838 } on : shardl { "t" : 8, "i": 0 } 
ss 这 里 省 略 了 几 行 …… 

{ "id" : 412949 } -->> { "id" : 426349 } on : sharql { "t" : 6, "i": 4 } 
{ "id" : 426349 } -->> { "id" : 457636 } on : shardl { "t" : 7, "i" : 2 } 
{ "id" : 457636 } -->> { "id" : 471683 } on : shardl { "t" : 7, "i" : 4 } 
{ "id" : 471683 } -->> { "id" : 486547 } on : shardl { "t" : 7, "i" : 6 } 
{ "id" : 486547 } -->> { "id" : { SmaxKey : 1 } } on : shardi { "t" : 7, "i" : 7 } 


db.printShardingStatus() 可 以 打印 出 一 个 包含 所 有 分 片 和 数据 库 的 列表 。 每 
个 分 片 集合 一 个 条 目 〈 这 儿 只 有 一 个 分 片 集合 test.foo)。 它 会 显示 出 数据 块 的 分 布 
情况 (shard0001 上 15 个 块 ， 而 shard0000 上 16 个 块 )。 然 后 是 每 个 块 的 详细 信 
息 ， 包 括 它 的 区 间 (比如 { "ia" : 115882 } -->> { "ia" : 130403 } 对 
应 _id 在 区 间 [115882, 130403) 里 的 文档 ) 和 它 所 在 的 分 片 。 它 还 会 给 出 块 的 主 次 
版 本 号 ， 这 个 不 需要 关心 。 











创建 的 每 个 数据 库 都 有 一 个 主 分 片 作 为 “大 本 营 ”。 在 这 个 例子 里 ，test 数据 库 的 主 
分 片 被 随机 设 定 为 shard0000。 这 并 不 意味 任何 东西 一 一 shard0001 最 后 比 shard0000 
的 数据 块 还 多 ! 这 个 字段 应 该 永远 与 你 无 关 ， 所 以 可 以 忽略 它 。 如 果 删 除 掉 某 个 数 
据 库 的 主 分 片 ， 则 其 主 分 片 会 被 自动 地 移动 到 集群 中 另 一 个 分 片上 。 
集合 很 大 的 话 ，dp .printshardingstatus () 的 输出 就 会 特别 长 ， 因 为 要 列 出 每 
个 分 片上 的 每 个 块 。 如 果 集 群 非常 大 ， 通 过 深入 研究 能 够 得 到 更 多 准确 的 信息 ， 但 
是 如 果 你 刚 上 道 ， 那 么 这 个 漂亮 的 概览 正 合适 。 








5.1.2 配置 集合 

mongos 会 将 请 求 分 发 到 适当 的 分 片上 ， 除 非 查 询 的 是 config 数据 库 。 访 问 config 
数据 库 会 直接 转 到 配置 服务 器 上 去 ， 而 那 正 是 能 找到 所 有 集群 配置 信息 的 地 方 。 如 
果 你 的 集合 由 几 百 或 几 千 个 数据 块 组 成 ， 那 就 值得 了 解 一 下 config 数据 库 的 内 容 ， 
以 便 能 够 查询 特定 信息 ， 而 非 获 得 整个 集群 的 概况 。 


让 我 们 看 看 config 数据 库 。 假 设 你 有 一 个 集群 ， 应 该 能 看 见 以 下 集 








n> 


> use config 
switched to db config 
> show collections 
changelog 

chunks 

collections 
databases 
lockpings 

locks 

mongos 

settings 

shards 
system.indexes 


version 


其 中 很 多 都 对 应 集群 config.mongos (所 有 mongos 进程 的 列表 ， 包 括 过 去 和 现在 的 ) 
的 组 成 部 分 。 


> db.mongos.find() 


u idt- "ubuntu:10000", "ping" : ISODate("2011-01-08T10:11:23"), "up" s 0 
= P P 
{ "id" : "ubuntu:10000", "ping" : ISODate("2011-01-08T10:11:23"), "up" : 20 } 
{ "id" : "ubuntu:10000", "ping" : ISODate("2011-01-08T10:11:23"), "up" : 1 } 





_id Æ mongos 的 主机 名 。ping 是 配置 服务 器 最 后 一 次 ping 它 的 时 间 。up 是 它 认 
为 mongos 是 否 在 线 。 如 果 启 动 了 一 个 mongos， 即 使 只 是 几 秒 钟 ， 它 都 会 被 添加 到 
这 个 列表 中 且 不 会 消失 。 这 并 不 重要 ， 因 为 你 不 太 可 能 会 启动 数 百 万 个 mongos 服 
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务 器 ， 不 过 还 是 需要 提醒 一 下 ， 这 样 看 到 列表 时 才 不 会 感到 困惑 。 


集群 中 的 所 有 分 片 。 

集群 中 的 所 有 数据 库 (包括 分 片 版 和 未 分 片 版 )。 

所 有 分 片 集合 。 

集群 中 的 所 有 数据 块 。 

config.settings 包含 (理论 上 ) 与 数据 库 版 本 相关 的 可 调 设 置 。 目 前 ，config.settings 
允许 调整 块 大 小 (但 是 别 这 么 做 ! ) 和 关闭 平衡 器 ， 通 常情 况 下 都 不 需要 这 么 做 。 
可 以 通过 执行 一 个 更 新 来 修改 这 些 设置 。 比 如 ， 要 关 掉 平衡 器 : 








config.shards 





config.databases 





config.collections 





config.chunks 


— 





> db.settings.update({"_id" : "balancer"}, {"$set" : {"stopped" : true }}, true) 
如 果 正 处 在 一 轮 平 衡 化 过 程 中 ， 则 直到 完成 为 止 平衡 器 都 不 会 关闭 。 
剩 下 的 集合 中 唯一 可 能 需要 关注 的 就 是 config.changelog。 它 是 一 个 非常 详尽 的 日 


志 ， 其 中 记录 了 每 一 次 发 生 的 分 割 和 迁移 ， 可 以 用 于 跟踪 使 集群 变 成 当前 配置 状态 
的 步骤 。 不 过 ， 通 常 它 都 比 需要 的 更 详尽 。 


5.1.3 应 该 连接 什么 
如 果 执 行 的 只 是 正常 的 读 写 或 管理 操作 ， 答 案 永远 是 “mongos”。 它 可 以 是 任何 mongos 
( 记 住 它们 是 无 状态 的 )， 但 永远 是 mongos， 而 不 是 分 片 ， 也 不 是 配置 服务 器 。 


如 果 操 作 并 不 寻常 ， 可 能 就 要 连接 配置 服务 器 或 分 片 了 。 也 许 是 为 了 直接 查看 某 个 
分 片 的 数据 或 是 手动 修改 一 个 被 搞 乱 的 配置 。 比 如 ， 你 必须 直接 连 到 分 片上 才能 修 
改 副 本 集 的 配置 。 

记 住 配置 服务 器 和 分 片 都 只 是 一 般 的 mongod 而 已 。 你 所 知道 的 任何 在 mongod 上 
执行 的 操作 都 同样 适用 于 配置 服务 器 和 分 片 。 尽 管 如 此 ， 在 正常 的 运 维 过 程 中 ， 应 
该 几乎 永远 不 需要 连接 它们 。 所 有 正常 的 操作 都 应 该 通过 mongos 完成 。 


























5.2 监控 


当 你 有 一 个 集群 时 ， 监 控 非 常 重要 。 所 有 对 监控 单个 节点 的 建议 都 适用 于 监控 多 个 
市 点 ， 因 此 请 确保 已 读 过 有 关 监 控 的 文档 。 


注意 ， 当 机 器 数量 变 多 时 ， 网 络 会 变 得 越 来 越 重要 。 如 果 一 台 服 务 器 表示 连 不 上 男 
一 台 服 务 器 ， 要 检查 两 台 服 务 器 间 网 络 的 连通 性 。 


如 果 可 能 ， 请 保留 一 个 已 经 连 上 集群 的 shell。 创 建 一 个 连接 要 求 MongoDB 暂时 给 








连接 一 个 锁 ， 这 在 调试 时 可 能 是 个 问题 。 假 设 一 台 服 务 器 出 状况 了 ， 因 此 你 启动 一 
个 shell 去 连 它 。 非 常 遗 憾 的 是 ，mongod 正好 卡 在 写 锁 上 ， 因 此 shell 会 一 直 尝 试 获 
取 锁 ， 进 而 永远 也 不 能 完成 连接 。 所 以 为 了 安全 起 见 ， 留 下 一 个 打开 的 shell。 





5.2.1 mongostat 

mongostat 是 可 用 监控 工具 中 最 全 面 的 。 它 能 返回 大 量 与 服务 器 运行 有 关 的 信息 ， 包 
括 负载 、 页 错误 及 打开 的 连接 数 。 

如 果 有 一 个 集群 ， 你 可 以 为 每 台 服 务 器 单独 启动 一 个 mongostat， 也 可 以 在 某 个 mongos 
上 运行 mongostat --discover 并 让 它 来 分 析出 集群 的 所 有 成 员 并 显示 其 状态 。 


举 个 例子 ， 如 果 我 们 使 用 第 4 章 描 述 的 simple-setup.py 脚本 启动 了 一 个 集群 ， 它 能 
找 出 所 有 的 mongos 进程 和 分 片 : 








$ mongostat --discover 


mapped vsize res faults locked% idx miss com time repl 
localhost :27017 Om 105m 3m 0 0 0 2 22:59:50 RTR 
Localhost :30001 80m 175m 5m 0 0 0 3 22:59:50 
localhost :30002 Om 95m 5m 0 0 0 3 22:59:50 
Localhost : 30003 Om 95m 5m 0 0 0 3 22:59:50 
localhost :27017 Om 105m 3m 0 0 0 2 22:59:51 RTR 
localhost :30001 80m 175m 5m 0 0 0 3 22:59:51 
localhost : 30002 Om 95m 5m 0 0 0 3 22:59:51 
localhost :30003 om 95m 5m 0 0 0 3 22:59:51 








我 简化 了 输出 并 删除 了 一 些 列 ， 因 为 每 行 只 能 放下 80 个 字符 ， 而 mongostat 一 行 有 
EE 166 个 字符 宽 。 另 外 空 行 看 上 去 也 有 点 奇怪 ， 因 为 这 个 工具 以 “正常 ”mongostat 
空 行 开始 ， 列 出 集群 的 剩余 部 分 ， 还 要 再 添加 两 个 字段 grl gqw 和 arlaw。 这 些 字 
段 分 别 显示 了 有 多 少 连 接 在 读 和 写 操作 上 排队 等 待 以 及 有 多 少 处 于 活动 状态 的 读 写 
操作 。 





5.2.2 Web 管理 界面 

如 果 使 用 副本 集 ， 请 确保 使 用 --rest 选项 启动 它们 。 副 本 集 的 Web 管理 界面 
(hitp:/Nocalhost:28017/_replSet, 40% mongod 是 在 端口 27017 上 运行 的 ) 可 以 给 出 
大 量 的 相关 信息 。 





5.3 备份 


在 运行 的 集群 上 做 备份 其 实 是 非常 有 难度 的 。 数 据 不 停 地 被 应 用 程序 添加 和 删除 ， 
同时 又 照例 被 平衡 器 挪 来 挪 去 。 若 今天 转 储 一 个 分 片 明天 再 恢复 ， 就 有 可 能 有 某 些 
文档 同时 出 现在 两 处 或 者 彻底 丢失 〈 见 图 5-1) 的 情况 。 

















图 5-1: 迁移 前 做 了 备份 。 如 果 迁 移 后 分 片 崩溃 并 从 备份 中 恢复 ， 则 集群 会 失去 被 迁移 的 块 


创建 备份 的 问题 在 于 通常 你 只 想 要 恢复 集群 的 一 部 分 (你 不 会 想 从 昨天 的 备份 中 恢 
复 整 个 集群 ， 而 只 是 想 恢复 停机 的 那个 节点 )。 如 果 要 从 备份 中 恢复 ， 必 须 小 心 齐 
慎 。 首 先 查 看 一 下 配置 服务 器 ， 明 确 哪些 数据 块 应 该 在 要 被 恢复 的 分 片上 ， 然 后 只 
从 备份 中 恢复 这 些 块 的 数据 (还 有 mongorestore)。 
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WOR AD SEE RTE — ARR, AB IE LR AE tat, foync 并 锁 住 集群 中 的 所 有 从 
机 ， 转 储 ， 然 后 对 其 解锁 并 重 局 平衡 器 。 通 常人 们 只 是 从 个 别 分 片上 提取 备份 。 


5.4 关于 架构 的 建议 
你 可 以 创建 一 个 分 片 集群 然后 不 再 动 它 ， 但 常规 维护 怎么 做 ”为 了 让 集群 更 容易 管 
理 ， 可 以 在 架构 上 多 花 些 心思 。 





























5.4.1 创建 应 急 站 点 

名 字 上 暗示 了 正在 运行 的 是 一 个 Web 站 点 ， 不 过 这 一 方法 对 多 数 类 型 的 应 用 程序 都 适 
用 。 如 果 需 要 让 应 用 偶尔 下 线 (比如 进行 系统 维护 、 更 改 ， 或 者 处 于 紧急 情况 时 )， 
有 个 可 以 切换 过 去 的 应 急 站 点 就 显得 非常 便利 了 。 


应 急 站 点 完全 不 应 使 用 自己 的 数据 库 集 群 。 如 果 要 使 用 某 个 数据 库 ， 则 此 数据 库 应 
当 与 主 数据 库 完 全 断 开 连 接 。 你 也 可 以 让 它 通 过 缓存 提供 数据 ， 要 不 就 把 整个 应 
急 站 点 做 成 静态 的 ， 这 取决 于 应 用 程序 。 不 管 怎样 做 一 点 东西 给 用 户 看 总 比 显 示 
Apache 的 错误 页 面 好 。 











5.4.2 ” 挖 护 城 河 
有 一 个 好 办 法 能 阻止 或 最 小 化 各 类 问题 ， 那 就 是 在 集群 服务 器 周围 挖 出 一 条 “虚拟 
护城河 "， 然 后 通过 队列 控制 对 集群 的 访问 。 


队列 可 以 让 应 用 程序 在 计划 的 中 断 运行 时 继续 处 理 写 人 ， 或 者 至 少 避 免 在 中 断 运 行 
开始 前 丢失 那些 尚未 完成 的 写 人 。 你 可 以 将 它们 保存 在 队列 中 直到 MongoDB 再 次 
启动 为 止 ， 然 后 再 把 它们 发 送 给 mongos。 


队列 不 仅 在 容 灾 中 非常 有 用 ， 而 且 在 常规 的 突 发 流量 下 也 非常 有 用 。 队 列 可 以 吸收 
短 时 间 内 爆发 的 大 量 请 求 并 释放 出 一 个 和 缓 稳定 的 请 求 流 ， 而 不 是 让 突 发 的 请 求 洪 
流 瓷 没 集群 。 你 也 可 以 把 队列 反 过 来 用 ， 即 缓存 MongoDB 返回 的 结果 。 

有 很 多 不 同 的 队列 可 供 使 用 ， 包 括 Amazon SQS、RabbitMQ ， 甚 至 是 一 个 MongoDB 
集合 〈 当 然 一 定 得 把 它 和 被 保护 的 集群 分 开 来 ) ， 随 便 哪 种 只 要 用 起 来 舒坦 就 行 。 


不 过 ， 队 列 也 不 是 对 所 有 类 型 的 应 用 都 有 效 ， 比 如 对 需要 实时 数据 的 应 用 就 没什么 
帮助 。 尽 管 如 此 ， 如 果 应 用 程序 可 以 忍受 微小 的 延迟 ， 队 列 能 够 在 外 部 世界 和 数据 
库 之 间架 起 一 座 非 常 有 价值 的 桥梁 。 
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5.5 ”错误 处 理 


正如 第 1 章 提 到 的 ， 网 络 分 区 (network partition)、 服 务 器 月 滥 以 及 其 他 问题 能 够 
引发 各 式 各 样 的 麻烦 。 很 多 情况 下 MongoDB 可 以 (至少 和 暂时) 从 这 类 麻烦 中 “ 自 
愈 " 。 这 一 节 会 介绍 遇 到 哪些 问题 可 以 不 用 处 理 尽 管 放心 大 睡 ， 而 对 哪些 问题 却 不 能 
置之不理 ， 同 时 介绍 如 何 让 应 用 程序 准备 好 应 对 各 种 运行 中 断 。 


5.5.1 分 片 停机 
如 果 一 整个 分 片 都 停机 了 ， 则 所 有 应 该 命中 该 分 片 的 读 写 都 会 返回 错误 。 应 用 程序 
应 该 处 理 这 种 错误 (无论 使 用 何 种 编程 语言 ， 这 都 如 同 在 遍历 游标 时 抛 出 的 异常 )。 
举例 来 说 ， 如 果 一 个 查询 的 头 3 个 结果 在 运行 正常 的 分 片上 ， 而 包含 有 用 数据 块 的 
第 四 个 分 片 却 停 机 了， 你 会 得 到 这 样 的 输出 : 

> db.foo.find() 

{ "4a" :1} 

{ "ia" : 2} 

{ "4a" : 3 } 

error: mongos connectionpool: 

connect failed ny-01:10000 : couldn’ t connect to server ny-01:10000 


i RR eA Eee, CAPE SL) ES AT ELE Eir PSS. mA ee 
序 而 言 ， 也 可 以 有 针对 性 地 继续 查询 直至 分 片 重新 上 线 为 止 。 

未 来 MongoDB 会 增加 对 部 分 查询 结果 的 支持 (post-1.8.0)， 这 样 就 可 以 只 从 正常 运 
行 中 的 分 片 返 回 结果 而 不 指出 发 生 的 任何 异常 。 


5.5.2 多数 分 片 停机 

如 果 用 副本 集 做 分 片 ， 则 理想 情况 下 整个 分 片 不 会 全 停 掉 ， 而 仅仅 是 其 中 的 一 两 台 
服务 器 。 如 果 副 本 集 失 去 了 多 数 成 员 ， 则 没有 服务 器 能 成 为 主机 (除非 重新 进行 人 
工 调整 )， 集 合 就 会 变 成 只 读 状 态 。 ' 一 旦 它 变 为 只 读 状 态 ， 就 要 确保 应 用 程序 仅 发 
送 给 它 带 有 slaveOkay 选项 的 读 请 求 。 


如 果 使 用 了 副本 集 ， 则 理想 情况 下 单个 服务 器 (其 至 是 一 些 服 务 器 ) 出 错 完 全 不 会 影响 
到 应 用 程序 。 集 合 中 剩余 的 服务 器 会 承担 起 负载 ， 而 应 用 甚至 不 会 注意 到 发 生 的 变化 。 


e 在 1.6 版 中 ， 如 果 一 个 副本 集 配置 发 生变 化 ,日 志 里 会 出 现 大 量 重复 消息 。 
因为 mongos 和 分 片 间 的 每 一 条 连接 都 在 注意 到 副本 集 连 接 已 过 期 时 执行 
更 新 ， 而 它 更 新 时 就 会 打印 一 条 消息 。 尽 管 如 此 ， 这 应 该 不 会 对 运行 造成 
影响 ， 而 只 是 有 些 喝 吴 吵闹 而 已 。 在 1.8 版 本 中 这 个 问题 已 经 被 修复 了 ， 
那 之 后 在 更 新 副本 集 配 置 的 事情 上 ，mongos 变 得 聪明 多 了 。 

译注 1: 2.0 版 本 已 发 生变 化 ， 详 情 风 http://www.mongodb.org/display/DOCS/2.0+Releaset+Notes#2.0Release- 


NotesReconfigurationwithaminorityup 。 












































5.5.3 配置 服务 器 停机 

一 台 配 置 服务 器 停机 并 不 会 立即 对 集群 的 性 能 产生 影响 ， 但 是 却 会 导致 无 法 修改 任 
何 配置 。 所 有 配置 服务 器 必须 协同 工作 ， 因 此 只 要 是 一 个 兄弟 倒 下 了 ， 剩 下 的 配置 
服务 器 都 不 再 允许 任何 修改 。 要 注意 的 是 ， 配 置 服务 器 停机 时 不 能 修改 任何 配置 ， 
比如 不 能 添加 mongos 服务 器 ， 也 不 能 迁移 数据 ， 也 不 能 添 删 数 据 库 或 集合 ， 当 然 
也 不 能 修改 副本 集 的 配置 。 


如 果 一 台 配 置 服务 器 崩 涡 了， 务必 要 让 它 重启 以 便 能 在 需要 的 时 候 修改 配置 但 它 
应 该 完全 不 会 影响 到 集群 当时 的 操作 。 请 确保 监控 了 配置 服务 器 ， 并 且 如 果 一 台 坏 
掉 了 ， 就 让 它 尽 快 恢 复 。 


数据 迁移 期 间 配 置 服务 器 坏 掉 是 会 给 服务 器 带 来 一 些 压力 的 。 迁 移 的 最 后 儿 步 之 一 
就 是 更 新 配置 服务 器 。 因 为 只 要 一 个 服务 器 停机 了 就 全 部 无 法 更 新 ， 所 以 分 片 不 得 
不 回 退 迁移 并 删除 准 辛 苦 苗 复制 完 的 所 有 数据 。 如 果 分 片 没有 过 载 ， 那 么 不 至 于 太 
悲剧 ， 可 惜 有 点 浪费 。 








5.5.4 mongos 进 程 死 掉 

由 于 你 总 是 可 以 有 很 多 mongos 进程 ， 而 且 它 们 没有 状态 ， 所 以 如 果 其 中 一 个 坏 掉 
了 也 不 是 什么 大 事 。 推 荐 在 每 个 应 用 程序 服务 器 上 跑 一 个 mongos 并 且 让 每 个 应 用 
程序 服务 器 和 它 本 地 的 mongos 通信 ( 见 图 5-2)。 这 样 的 话 ， 如 果 整 个 机 器 停 掉 ， 
也 不 会 有 人 尝试 与 一 个 不 存在 的 mongos 进程 对 话 。 











应 用 程序 服务 器 











5-2: 运行 了 mongos 的 应 用 程序 服务 器 
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预备 一 些 元 余 的 mongos 服务 器 ， 这 样 如 果 一 个 mongos 进程 坏 掉 而 应 用 程序 服务 器 
还 正常 ， 就 可 以 将 故障 转移 到 其 他 mongos 上 。 大 部 分 驱动 允许 声明 一 组 可 连接 的 
服务 器 并 会 按 顺序 尝试 连接 。 因 此 你 可 以 把 首选 的 mongos 放 在 前 面 ， 后 面 跟着 备 
用 的 mongos。 如 果 一 个 坏 掉 了 ， 应 用 程序 可 以 处 理 异 常 〈 用 你 使 用 的 任何 语言 )， 
然后 驱动 会 自动 为 下 一 个 请 求 切换 后 备 服务 器 。 


由 于 mongos 无 状态 且 不 保存 数据 ， 如 果 机 器 是 好 的 ， 你 也 可 以 只 是 尝试 重启 崩溃 
掉 的 mongos。 











5.5.5 ”其 他 注意 事项 

以 上 各 点 在 处 理 时 都 应 该 与 其 他 任何 可 能 出 问题 的 地 方 隔 离开 来 。 有 时 ， 由 于 网 络 
分 区 你 有 可 能 会 失去 全 部 分 片 ， 或 一 部 分 其 他 分 片 或 配置 服务 器 或 者 mongos 进程 。 
建议 你 从 面向 用 户 〈 用 户 还 能 做 什么 ?” ) 和 程序 设计 (应 用 程序 还 能 切合 实际 地 做 
什么 ?) 两 个 角度 审慎 考虑 如 何 应 对 各 种 场景 。 

最 后 ，MongoDB 在 显露 功能 丧失 症状 前 会 尽力 承受 各 种 错误 。 当 然 ， 如 果 遇 上 了 完 
美 风 暴 (一 定 会 ) ， 难 免 会 失去 功能 ， 但 是 平日 里 的 服务 器 崩 祺 ， 电 力 短 缺 以 及 网 络 
分 区 不 应 该 造成 太 大 的 问题 。 敬 请 死 盯 监控 保持 镇 定 ， 呵 护 好 你 的 集群 。 
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学 习 资 源 


如 果 你 按照 前 面 各 章 给 出 的 意见 做 了 ， 那 么 就 应 该 能 够 顺利 地 构建 一 个 高 效 且 可 预 
测 的 分 布 式 系统 ， 还 能 按 需 增 长 。 如 果 你 还 有 问题 和 其 他 困惑 ， 请 发 电子 邮件 给 我 ， 
我 的 邮箱 是 kristina@ 10gen.com。 





如 果 你 有 兴趣 进一步 学 习 分 片 ， 这 里 有 些 可 用 的 资源 。 


e MongoDB 的 wiki 有 很 大 篇 幅 介绍 了 分 片 的 内 容 ， 包 括 了 从 配置 示例 到 内 部 机 制 的 
详细 内 容 。 

。 MongoDB 用 户 列 表 是 一 个 提问 的 好 地 方 。 

。 在 mongo-snippets 源码 库 里 有 很 多 有 用 的 代码 片段 。 

e Boxed Ice 在 生产 环境 中 部 署 了 一 个 MongoDB 集群 并 且 经 常 在 博客 上 写 一 些 与 运 
行 MongoDB 相关 的 实用 文章 。 

。 如 果 你 有 兴趣 阅读 更 多 有 关 分布 式 计算 的 理论 ， 我 强烈 推荐 Leslie Lamport 关于 
Paxos 算法 论文 ， 该 论文 非常 有 趣 且 有 局 发 性 。 








另外 ， 如 果 你 喜欢 这 本 书 ， 建 议 你 阅读 我 的 博客 ， 甚 中 主要 是 一 些 关 于 MongoDB 
的 高 级 话题 。 





ongoDB 开 发 技巧 50 例 





50 Tips and Tricks for MongoDB Developers 





[Æ] Kristina Chodorow 著 
程 显 峰 译 
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MongoDB 上 手 很 容易 ， 但 是 一 旦 用 它 来 构建 应 用 ， 一 些 棘手 的 问题 便 会 接 足 而 来 。 
究竟 该 怎样 设计 数据 架构 ? 拆 分 成 两 个 文档 还 是 放 在 一 块 儿 ? 性 能 如 何 提高 ?本 书 
正 是 用 来 解答 这 些 问 题 的 。 

本 书 涵盖 的 技巧 分 为 若干 主题 : 

第 1 章 讲 述 数 据 库 设计 的 方方面面 ; 

第 2 章 讲 的 是 编写 应 用 程序 时 应 该 注意 的 问题 ， 

第 3 章 旨 在 为 应 用 提速 ; 

第 4 章 讲述 怎样 做 到 在 不 太 损 失 性 能 的 前 题 下 提高 数据 的 安全 性 ， 主 要 利用 复制 和 
日 志 来 做 到 这 一 点 

第 5 章 是 配置 和 运 维 的 经 验 总 结 。 

很 多 技巧 涉及 多 章 内 容 ， 尤 其 是 与 性 能 相关 的 。 第 3 章 主 要 针对 索引 进行 讲述 ， 但 
是 性 能 涉及 诸多 方面 ， 不 论 是 数据 设计 、 实 现 ， 还 是 数据 安全 都 会 对 其 有 影响 。 


读者 对 象 

本 书 适合 已 经 有 些 MongoDB 基础 知识 的 使 用 者 。 若 是 对 MongoDB 不 了 解 ， 可 以 
AA (MongoDB 权威 指南 》 或 者 在 线 文 档 (http://www.mongodb.org ) 。 

格式 约定 

本 书 使 用 了 如 下 排版 约定 。 

。 楷 体 

用 于 标记 新 名 词 。 
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程序 代码 ， 在 段落 中 用 于 表示 程序 的 组 成 部 分 ， 如 变量 或 函数 名 、 数 据 库 、 数 
型 、 环 境 变量 、 语 句 、 关 键 字 。 





命令 或 是 其 他 应 该 由 用 户 输入 的 内 容 。 





这 个 图 标 表示 提示 、 建 议 或 一 般 性 的 注解 。 





这 个 图 标 表 示 一 个 警告 或 警示 














使 用 示例 代码 

本 书 用 于 帮助 你 完成 工作 。 通 常 ， 你 可 以 在 程序 或 文档 中 使 用 本 书 提供 的 代码 。 除 
非 你 在 重新 发 布 我 们 的 大 量 代 码 ， 否 则 不 需要 联系 我 们 来 获得 许可 。 比 如 ， 在 程序 
中 使 用 本 书 代码 的 一 些 片段 是 无 需 我 们 许可 的 。 Paa e 
示例 光盘 显然 是 需要 授权 的 。 引 用 本 书 或 引用 示例 代码 来 回答 问题 是 不 需要 授权 的 ， 
但 将 本 书 的 大 量 示 例 代 码 纳 入 产品 的 文档 是 需要 授权 的 。 


我 们 乐于 见 到 你 在 使 用 时 声明 引用 信息 ， 但 不 强制 要 求 。 引 用 信息 通常 包括 书 
名 、 作 者 、 出 版 社 和 IJISBN， 例 如 “50 Tips and Tricks for MongoDB Developers 
by Kristina Chodorow (O’Reilly). Copyright 2011 Kristina Chodorow, 978-1-449- 
30461-4”, 


























如 果 你 认为 对 示例 代码 的 使 用 需要 授权 ， 请 通过 这 个 邮箱 联系 我 们 : permissions @ 


oreilly.com, 


Safar 在 线 图 书 
oo) Safari 在 线 图 书 是 应 需 而 变 的 数字 图 书馆 。 它 能 够 让 你 非常 轻 
Safari F 松 地 搜索 7500 多 种 技术 性 和 创新 性 参考 书 以 及 视频 ， 以 便 快 
Books Online 。 速 地 找到 需要 的 答案 
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订阅 后 你 就 可 以 访问 在 线 图 书馆 内 的 所 有 页 面 和 视频 ， 在 手机 或 其 他 移动 设备 上 阅 
读 ， 在 新 书 上 市 之 前 抢先 阅读 ， 还 能 够 看 到 尚 在 创作 中 的 书稿 并 向 作者 反馈 意见 。 
复制 粘贴 代码 示例 、 放 入 收藏 夹 、 下 载 部 分 章节 、 标 记 关 键 点 、 做 笔记 甚至 打印 页 
面 等 有 用 的 功能 可 以 帮 你 节省 大 量 时 间 。 


这 本 书 也 在 其 中 。 欲 访问 本 书 的 英文 版 电子 版 ， 或 者 由 0’ Reilly 或 其 他 出 版 社 出 版 
的 相关 图 书 ， 请 到 http://my.safaribooksonline.com 免费 注册 。 

我 们 的 联系 方式 

请 把 对 本 书 的 评论 和 问题 发 给 出 版 社 。 

美国 : 


O’Reilly Media, Inc. 
1005 Gravenstein Highway North 
Sebastopol, CA 95472 

















中 国 





北京 市 西城 区 西直门 南大 街 2 号 成 馈 大 厦 C 座 807 室 (100035) 
奥 莱 利 技术 咨询 (北京 ) 有 限 公 司 


O’Reilly 的 每 一 本 书 都 有 专属 网 页 ， 你 可 以 在 那儿 找到 本 书 的 相关 信息 ， 包 括 勘误 
表 、 示 例 代 码 以 及 其 他 信息 。 本 书 的 网 站 地 址 是 : 





http://oreilly.com/catalog/978 1449304614 





中 文书 : 
http://www.oreilly.com.cn/index.php?func=book&isbn=9787115272119 

对 于 本 书 的 评论 和 技术 性 问题 ， 请 发 送 电 子 邮件 到 : 
bookquestions @ oreilly.com 

关于 本 书 的 更 多 信息 、 会 议 、 资 源 中 心 和 网 络 ， 请 访问 以 下 网 站 : 


http://www.oreilly.com 


http://www.oreilly.com.cn 
我 们 在 Facebook 的 地 址 如 下 : 


http://facebook.com/oreilly 





请 关注 我 们 的 Twitter 动态 
http://twitter.com/oreillymedia 


我 们 的 YouTube 视频 地 址 如 下 : 
http://www.youtube.com/oreillymedia 
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应 用 设计 技巧 


1.1 技巧 1: 速度 和 完整 性 的 折 中 


在 多 个 文档 中 使 用 的 数据 既 可 以 采用 内 瞬 〈 反 范式 化 ) 的 方式 ， 也 可 以 采用 引用 
(范式 化 ) 的 方式 。 两 种 策略 并 没有 优 劣 之 分 ， 各 自 都 有 优 缺 点 ， 关 键 是 要 选择 适合 
自己 的 应 用 场景 的 方案 。 
反 范 式 化 会 产生 不 一 致 的 数据 。 举 例 说 明 ， 假 设 要 将 图 1-1 中 的 苹果 改 成 梨 。 假 如 
仅仅 更 新 了 一 个 文档 的 值 ， 应 用 就 崩溃 了 ， 而 你 还 没 来 得 及 更 新 其 他 文档 ， 这 时 数 
据 库 中 fruit 就 有 两 个 不 同 的 值 。 








food 


laine, 














1-1: 反 范 式 化 的 设计 。fruit 的 值 同时 存储 在 food 和 meals 集合 里 


不 一 致 可 不 太 好 ， 但 不 太 好 的 程度 取决 于 到 底 存 了 什么 。 对 于 很 多 应 用 来 说 ， 短 时 
的 不 一 致 还 说 得 过 去 。 如 果 有 人 更 改 了 用 户 名 ， 而 他 原 有 的 博客 文章 在 几 个 小 时 内 
还 显示 他 的 旧 用 户 名 也 没什么 大 不 了 的 。 要 是 不 能 容忍 哪怕 一 丁点 不 一 致 ， 则 应 该 
选用 范式 化 的 设计 。 

但 要 是 做 了 范式 化 ， 应 用 则 必须 在 每 次 确认 水 果 时 做 额外 一 次 查找 (图 1-2). FE 
应 用 无 法 承担 这 样 的 负载 ， 又 不 太 强 调 一 致 性 ， 则 应 该 反 范 式 化 。 











food 


_id:x | 
fruit :@ 














1-2: 范式 化 的 设计 。fruit 字段 存储 在 food REE, W meals 集合 中 的 文档 引用 





应 用 设计 技巧 | 67 


这 里 需要 的 是 两 相 权衡 ， 因 为 极 高 的 性 能 和 瞬间 一 致 性 不 可 兼 得 。 所 以 必须 要 想 清 
楚 哪 个 才 是 应 用 最 需要 的 特性 。 


1.1.1 示例 : 网 上 购物 车 
假设 现在 要 为 购物 车 设计 一 下 数据 结构 。MongoDB 中 要 存放 应 用 的 订单 ， 但 订单 
中 该 涵盖 哪些 信息 呢 ? 


范式 化 的 设计 
商 口 
HA: 
{ 
"id" : productId, 
"name" : name, 
"price" : price, 
"desc" : description 
} 
订单 : 
{ 
"id" : orderId, 
"user" : userinfo, 
"items" : [ 
productIidli, 
productIid2, 
productId3 


} 
每 个 订单 文档 中 存放 商品 的 _ia。 这 样 ， 当 需要 显示 订单 内 容 时 ， 可 以 查询 订单 集 
合 获得 相应 订单 ， 之 后 查询 商品 集合 获得 指定 id 的 商品 信息 。 这 种 设计 下 ， 一 次 
查询 无 法 获取 完整 的 订单 。 

若 有 商品 信息 更 新 了 ， 所 有 引用 此 商品 的 文档 都 会 “更 新 ”， 因 为 这 些 文档 只 是 指向 
了 保存 商品 信息 的 文档 。 








范式 化 的 结果 就 是 读 取 速度 较 慢 ， 但 所 有 订单 的 一 致 性 会 有 保证 。 多 个 文档 会 原子 
性 地 更 新 (因为 仅仅 引用 的 文档 会 更 新 )。 


反 范 式 化 设计 
商品 (与 前 面相 同 ) : 
{ 





"id" ; productid, 





"name" : name, 


"price" : price, 
"desc" : description 
订单 : 

i idr : orderId, 

"user" : userinfo, 

"items" : [ 
"id" : productIdi, 
"name" : namel, 
"price" : pricel 
"id" + productId2, 
"name" : name2, 
"price" : price2 
"id" ; productid3, 
"name" : name3, 
"price" : price3 


} 


XER m fe EAE CTE ETT i. GE, SANT) EIBH Atte 
查询 。 


如 果 商 品 信息 变化 了 ， 需 要 更 新 ， 就 要 改动 所 有 相应 的 订单 。 


反 范 式 化 读 取 速 度 较 快 ， 一 致 性 稍 弱 。 商 品 信息 的 变更 不 能 原子 性 地 更 新 到 多 个 
文档 。 


综 上 所 述 ， 你 决定 选 哪 个 了 吗 ? 


1.1.2 ”考虑 因素 
主要 应 考虑 以 下 几 点 。 





。 是 否 总 是 要 额外 读 取 一 次 几乎 不 怎么 改变 的 数据 ? 可 能 读 了 商品 信息 一 万 次 才 会 修 
改 一 次 它 的 详细 信息 。 为 了 那 一 次 写 入 快 一 点 或 者 保证 一 致 性 ， 搭 上 一 万 次 的 读 取 
消耗 值 吗 ? 绝 大 多 数 应 用 都 具有 高 读 写 比 ， 不 仿 测算 一 下 应 用 的 读 写 比 。 
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你 认为 引用 的 数据 多 入 会 更 新 一 次 ?更 新 越 少 ， 越 适合 反 范 式 化 。 有 些 极 少 变 化 
的 数据 几乎 根本 不 值得 引用 ， 例 如 名 字 、 生 日 、 股 票 代 码 、 地 址 。 


。 一 致 性 很 重要 么 ?如果 是 肯定 的 ， 则 应 该 范式 化 。 例 如 ， 多 个 文档 可 能 需要 原子 性 
地 更 新 。 如 果 设 计 的 是 一 个 交易 系统 ， 一 些 特定 的 证 券 必须 在 指定 的 时 间 交 易 ， 我 
们 就 会 希望 在 它们 不 能 交易 时 瞬时 将 其 全 部 “ 锁 ” 起 来 。 为 此 就 可 以 用 一 个 锁 文 档 
来 引用 这 组 证 券 文档 。 但 这 种 操作 最 好 在 应 用 层 处 理 ， 因 为 应 用 需要 知道 何 时 上 锁 
何 时 解锁 。 


另外 ， 当 应 用 中 的 不 一 致 性 难以 被 容忍 时 也 必须 首先 考虑 一 臻 性。 在 订单 的 例子 
中 ， 层 次 比较 严格 : 订单 从 商品 中 获取 信息 ， 但 商品 不 会 从 订单 中 获取 信息 。 假 
如 有 多 个 “信息 源 ” 文 档 ， 就 比较 难 取舍 了 。 
然而 ， 这 个 (构造 出 来 的 ) 订单 系统 中 ， 一致 性 反而 有 不 利 的 一 面 。 假 设 我 们 希 
望 将 某 个 商品 打 八 折 。 此 时 我 们 不 想 改 变 已 有 的 订单 的 任何 信息 ， 仅 仅 是 想 更 新 
一 下 商品 的 描述 。 这 里 我 们 要 的 是 某 一 时 刻 的 数据 快照 (参见 技巧 5)。 

。 要 不 要 快速 的 读 取 ? 若 想 读 取 尽 可 能 快 ， 则 要 反 缉 式 化 。 在 这 个 应 用 中 这 就 无 所 谓 
了 ， 所 以 不 能 算是 卷 量 因素 。 实 时 的 应 用 要 尽 可 能 地 反 范 式 化 。 

订单 文档 非常 适合 反 范 式 化 ， 因 为 其 中 的 商品 信息 不 经 常 变 化 ， 就 算 变 了 也 不 必 更 

新 到 所 有 订单 。 范 式 化 在 此 就 没什么 优势 可 言 了 。 

所 以 ， 本 例 中 最 佳 选择 是 将 订单 反 范 式 化 。 


延伸 阅读 : 


























e “Your Coffee Shop Doesn’t Use Two-Phase Commit” (咖啡 店 不 需要 两 步 提 交 ， 人 参见 
http://www.eaipatterns.com/docs/IEEE Software Design 2PC.pdf) 举例 说 明了 现实 世 
界 中 的 系统 怎样 处 理 一 致 性 ， 及 其 与 数据 库 设计 的 关系 。 


1.2 #2152: 适应 未 来 的 数据 要 范式 化 
范式 化 可 使 数据 可 用 性 更 长 入， 将 来 可 以 在 不 同 的 应 用 中 以 不 同 的 方式 查询 范式 化 
的 数据 。 


这 里 的 前 提 是 有 些 数据 将 会 年 复 一 年 不 断 地 被 各 种 应 用 用 到 。 的 确 有 这 种 数据 ， 但 
是 大 多 数 人 的 数据 都 会 不 断 地 演化 ， 陈 旧 的 数据 要 么 被 更 新 ， 要 么 就 被 丢弃 。 绝 大 
多 数 人 都 希望 数据 库 能 尽 可 能 地 对 当前 查询 做 出 快速 响应 ， 如 果 将 来 查询 变 了 ， 他 
们 会 针对 新 的 查询 优化 数据 库 。 
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还 有 ， 应 用 如 果 很 成 功 ， 其 数据 经 常会 高 度 定制 化 。 当 然 ， 这 并 不 是 说 这 些 数据 不 
能 用 在 别处 ， 而 且 你 很 可 能 至 少 想 要 对 数据 做 些 元 分 析 。 但 这 和 “适应 未 来 ”不 同 ， 
“适应 未 来 ”代表 满足 未 来 10 年 内 的 所 有 查询 。， 


1.3 ”技巧 3: 尽量 单个 查询 获取 数据 


Aa 





本 节 会 涉及 一 个 术语 一 应 用 单元 。 对 于 Web 应 用 或 者 移动 应 用 ， 可 以 
4 4 。 将 对 后 端的 一 次 请 求 视 作 一 个 应 用 单元 。 类 似 的 例子 还 有 : 

MO 。 对 于 桌面 应 用 ， 一 次 用 户 交互 算 作 一 个 应 用 单元 ; 

对 于 分 析 系 统 ， 一 个 图 表 的 加 载 算 作 一 个 应 用 单元 。 

应 用 程序 中 这 些 离散 的 应 用 单元 涉及 与 数据 库 的 交互 。 


















































MongoDB 的 数据 库 设 计 要 从 应 用 单元 的 查询 出 发 。 


1.3.1 示例 : 博客 

若 要 设计 博客 系统 ， 对 一 篇 博客 文章 的 请 求 或 许 就 是 一 个 应 用 单元 。 显 示 一 篇 文章 
时 ， 需 要 显示 内 容 、 标 答 、 作 者 信息 (虽然 可 能 不 是 全 部 个 人 信息 ) 以 及 评论 。 所 
以 ， 这 里 将 这 些 信息 都 嵌 到 文章 文档 中 ， 以 便 通 过 一 次 查询 就 能 获得 所 有 必要 信息 。 


记 住 是 每 页 一 次 查询 ， 不 是 一 个 文档 一 次 查询 ， 有 时 需要 返回 多 个 文档 ， 或 者 文档 
的 一 部 分 (并非 文档 的 所 有 内 容 )。 例 如 ， 主 页 上 要 显示 posts 集合 中 最 近 的 10 篇 
文章 ,但 只 显示 它们 的 标题 、 作 者 和 概要 : 





> db.posts.find({}, {"title" : 1, "author" : 1, "slug" : 1, "_id" : 0}).sort( 
. {"date" : -1}).limit (10) 


可 以 把 含有 指定 标签 的 最 新 20 篇 文章 输出 到 一 个 页 面 : 


> db.posts.find({"tag" : someTag}, {"title" : 1, "author" : 1, 
"slug" : 1, "_id" : 0}).sort({"date" : -1}).limit (20) 


还 有 一 个 独立 的 authors 集合 ， 存 放 每 位 作者 的 详细 信息 。 作 者 页 面 非常 简单 ， 仅 
需要 从 authors nai eal. 


> db.authors.findOne({"name" : authorName}) 


posts 集合 中 文档 的 一 部 分 信息 可 能 是 作者 文档 中 信息 的 一 个 子 集 (也许 是 作者 名 
和 头像 )。 








译注 1: 这 就 是 Knuth 所 说 的 过 早 优 化 。 
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注意 应 用 单元 不 一 定 非 要 对 应 单个 文档 ， 上 面 的 一 些 例子 仅仅 算是 巧合 (一 篇 文章 
Ala HR aE TCP) 但 是 ， 还 有 很 多 情况 下 一 个 应 用 单元 要 对 应 多 个 
文档 ， 但 只 通过 单条 查询 来 完成 这 种 请 求 。 





1.3.2 示例 : 相册 

假设 有 一 个 相册 ， 用 户 可 以 创建 或 者 回复 含有 照片 和 文字 的 帖子 。 有 个 应 用 单元 是 
查看 线索 中 的 20 条 回帖 ， 每 个 人 的 回复 都 是 posts 集合 中 一 个 独立 的 文档 。 要 显 
示 这 个 页 面 时 ， 只 需 这 样 查询 : 


> db.posts.find({"threadId" : id}).sort({"date" : 1}).limit (20) 
这 样 需要 查询 下 一 页 的 内 容 时 ， 就 查询 紧 接 着 的 20 条 内 容 : 


> db.posts.find({"threadId" : id, "date" : {"$gt" : latestDateSeen}}) .sort ( 
. {"date" : 1}).limit (20) 





还 可 以 创建 索引 {threadId : 1, date : 1} 来 优化 这 种 查询 的 性 
4S 能 。 H skip (20) 分 页 远 不 及 范围 高 效 ， 所 以 不 予 采纳 。 参 见 Aip:V/ 
o www.mongodb.org/display/DOCS/Advanced+ Queries#Advanced Queries- 
{{skip%28%29}}, 





Pee oa a ae 用 户 和 管理 人 员 不 断 要 求 新 功能 ， 即 使 一 个 应 用 单元 必须 得 多 

次 查询 ， 也 不 必 担 心 。 一 次 查询 ”的 目标 是 个 良好 的 起 点 ， 可 以 很 好 地 衡量 初始 的 
但 现实 并 非 完美 世界 。 稍 微 复杂 的 应 用 中 ， 经 常会 有 稀奇 古怪 的 功能 需要 多 
次 查询 。 


1.4 技巧 4: MAKERS 

当 在 租 入 和 引用 文档 之 间 犹 滞 不 决 时 ， 不 妨 想 想 查 询 的 目的 究 竞 是 为 了 获得 字段 本 

身 的 信息 ， 还 是 为 了 进一步 获取 更 广泛 的 信息 。 例 如 按照 某 个 标签 查询 应 该 返回 带 

有 该 标签 的 文章 ， 而 不 仅仅 是 标签 本 身 。 类 似 地 ， 对 于 查询 评论 ， 可 能 已 存在 一 个 

最 新 评论 列表 ， 但 人 们 更 希望 知道 是 哪 篇 文章 引发 了 评论 ， 除 非 你 的 应 用 就 是 以 评 
论 为 核心 的 。 


若是 从 关系 型 数据 库 迁 移 到 MongoDB， 联 结 表 就 是 重点 要 考虑 获 入 的 对 象 。 那 些 
仅 有 一 个 键 和 一 个 值 的 表 (如 标签 、 权 限 、 地 址 ) Æ MongoDB 中 几乎 都 应 该 做 藤 
入 处 理 。 


还 有 ， 若 是 某 些 信息 只 在 一 个 文档 中 使 用 ， 则 应 该 伐 进 这 个 文档 。 








1.5 技巧 5: RAR) SAE 
技巧 1 中 订单 的 例子 已 经 提 到 ， 当 一 个 商品 打折 或 者 换 了 图 片 ， 并 不 需要 更 改 原来 
订单 中 的 信息 。 类 似 这 种 特定 于 某 一 时 刻 的 时 间 点 数据 ， 都 应 做 租 入 处 理 。 


订单 文档 中 还 有 一 处 也 是 这 样 ， 地 址 也 是 这 种 时 间 点 数据 。 若 某 人 更 新 了 个 人 信息 ， 
那么 并 不 需要 更 改 其 以 往 的 订单 内 容 。 


1.6 技巧 6: 不 要 藤 入 不 断 增加 的 数据 

MongoDB 存储 数据 的 机 制 决定 了 对 数组 不 断 追 加 数据 是 很 低 效 的 。 在 正常 使 用 中 
数组 和 对 象 大 小 应 该 相对 固定 。 

PILL, ERA 20 个 子 文档 ,或 者 100 个 ， 或 者 1 000 000 个 都 不 是 问题 ， 关 键 是 提前 
这 么 做 ， 之 后 基本 保持 不 变 。 放 任 文档 增长 会 使 系统 慢 得 让 你 受 不 了 的 。 

评论 是 个 比较 特殊 的 地 方 ， 因 应 用 不 同 而 差别 较 大 。 对 大 多 数 应 用 而 言 ， 评 论 应 该 
内 内 到 所 依附 的 父 文 档 中 。 但 是 ， 有 些 系统 中 评论 本 身 自 成 条 目 ， 或 者 动 辑 成 百 上 
千 ， 这 种 情况 就 应 该 将 其 放 到 独立 的 文档 中 了 。 

还 有 个 例子 ,假设 正在 做 一 个 以 评论 为 核心 的 应 用 。 技 巧 3 中 相册 的 例子 与 此 有 点 
类 似 ， 主 要 的 内 容 就 是 评论 ， 这 时 将 其 作为 单独 的 文档 处 理 比 较 合适 。 


1.7 #157: 预 填充 数据 
如 果 已 经 知道 未 来 要 用 到 哪些 字段 ， 第 一 次 插入 时 就 带 着 这 些 字 段 会 比 用 到 时 再 创 
建 效 率 更 高 。 例 如 ， 做 一 个 网 站 分 析 的 应 用 ， 以 查看 一 天 当中 每 一 分 钟 有 多 少 用 户 
查看 不 同 的 页 面 。 设 置 一 个 pages 集合 ， 其 中 每 个 文档 表示 一 个 页 面 6 个 小 时 的 信 
息 。 而 且 要 按 分 钟 和 小 时 两 种 频率 来 存储 信息 : 

{ 























"id" : pageId, 


"Start" : time, 
"visits" : { 
"Minutes" : [ 
[numO, numl, ..., num59], 
[numO, numi, ..., num59], 
[numO, numi, ..., num59], 
[numO, numi, ..., num59], 
[numO, numl, ..., num59], 
[numO, numi, ..., num59] 
] 
"hours" : [numo, ..., num5] 
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这 样 做 有 个 明显 的 好 处 一 一 可 以 始终 知道 文档 的 形式 。 这 个 文档 有 一 个 以 当前 时 间 
为 开始 时 间 的 字段 ， 未 来 6 小 时 每 一 分 钟 的 数据 都 会 记录 在 另 一 个 字段 中 ， 然 后 是 
一 个 接 一 个 的 类 似 文档 。 


因此 ， 可 以 在 系统 负载 较 低 的 时 段 批量 插入 模板 文档 ， 或 者 将 这 个 工作 均匀 地 散布 
到 一 天 当中 。 插 入 的 文档 具有 类 似 下 面 的 结构 ， 将 someTime 替换 为 接 下 来 6 小 时 
的 开始 时 间 : 


{ 











"id" : pageId, 
"Start" : someTime, 
"visits" : { 
minutes" [ 
[0 D sesia Oly 
[Oy Oy cng “Od; 
[Oi 多 vcore 5 OTS 
[iy OH eag Oy 
[0 Ür waga Oy 
[0 O ws A 
My 
"hours [0 Oy 0, Uy OG, 0] 
} 


这 样 ， 当 增加 或 者 设置 这 些 计数 器 的 时 候 ，MongoDB 就 不 用 为 其 分 配 空间 了 ， 只 
更 新 已 输入 的 值 ， 这 要 快 得 多 。 


例如 ， 在 某 一 小 时 开始 的 时 候 ， 可 以 这 样 更 新 : 





> db.pages.update({"_id" : pageId, "start" : thisHour}, 
sas ("Sinc s {"visits.0.0" = 34} 

这 一 想法 也 适用 于 其 他 类 型 的 数据 ， 甚 至 集合 和 数据 库 也 可 以 用 类 似 的 方法 。 若 每 

天 都 要 使 用 新 的 集合 ， 最 好 也 提前 创建 。 


1.8 技巧 8: 尽 可 能 预先 分 配 空间 


这 个 技巧 与 技巧 6 和 技巧 7 关系 紧密 。 只 要 知道 文档 开始 比较 小 ， 后 来 会 变 为 确定 
的 大 小 ， 就 可 以 使 用 这 种 优化 方法 。 一 开始 插入 文档 的 时 候 ， 就 用 和 最 终 数 据 大 小 
一 样 的 垃圾 数据 填充 ， 即 添加 一 个 garbage 字段 (其 中 包含 一 个 字符 串 ， 串 大 小 与 
文档 最 终 大 小 相同 ) ， 然 后 马上 重 置 字段 。 








> collection.insert ({" id" : 123, /* other fields */, "garbage" : someLongString}) 
> collection.update({" id" : 123}, {"Sunset" : {"garbage" : 1}}) 


这 样 ，MongoDB 就 会 为 文档 今后 的 增长 分 配 足够 的 空间 。( 参 见 图 1-3.) 
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图 1-3: 如 果 存 储 文档 时 便 为 其 分 配 将 来 所 需 的 空间 ， 之 后 便 不 再 需要 移动 它 


1.9 技巧 9: 用 数组 存放 要 匿名 访问 的 内 获 数 据 
一 个 常见 的 问题 就 是 内 绒 的 信息 到 底 是 用 数组 存 还 是 用 子 文档 在 。 如 果 确 切 知道 要 
春 询 的 内 容 ， 则 要 用 子 文档 。 如 果 有 时 不 太 清楚 查询 的 具体 内 容 ， 则 要 用 数组 。 当 


知道 一 些 条 目的 查询 条 件 时 ， 通 常 该 使 用 数组 。 


假设 要 编写 一 款 游 戏 ， 甚 中 的 玩家 可 以 挑选 各 种 物品 。 我 们 可 以 对 玩家 的 文档 这 样 


建 模 : 
{ 
t Ad" EL, 
"items" : { 
"slingshot" : { 
"type" : "weapon", 
"damage" : 23, 
"ranged" : true 
}, 
"jart { 
"type" : "container", 
"contains" : "fairy" 
}, 
"sword" : { 
"type" : "weapon", 
"damage" : 50, 
"ranged" : false 
} 
} 
} 


假设 要 找 出 所 有 伤害 值 (damage) 大 于 20 的 武器 


。 子 文档 不 支持 这 种 查找 物品 
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(items) 的 方式 :“ 给 我 所 有 伤害 值 大 于 20 的 物品 ”"。 你 只 能 知晓 具体 某 种 物品 的 
信息 ， 如 “items .slingshot .damage ( 弹 马 的 伤害 值 ) AF 209%” w “items. 
sword.damage ( 剑 的 伤害 值 ) 大 于 20 吗 ” 等 。 


如 果 想 无 需 标 识 符 就 能 获得 某 项 的 信息 ， 就 要 用 数组 : 
{ 


" id" : "fred", 

"items" : [ 
"id" : "slingshot", 
"type" : "weapon", 
"damage" : 23, 
"ranged" ; true 
"iq" : "jar", 
"type" : "container", 
"contains" : "fairy" 
"Td" os. Msword",; 
"type" : "weapon", 
"damage" : 50, 
"ranged" : false 


} 


这 样 用 一 条 查询 ("items.damage" : {"Sgt" : 20}} 就 可 以 了 。 如 果 需 要 多 条 
件 查 询 〈 比 如 伤害 值 和 攻击 范围 )， 可 以 用 Selemmatch ( 见 http://www.mongodb. 
org/display/DOCS/Advanced+Queries#Advanced Oueries-%24elem Match) 。 





那么 什么 时 候 该 用 子 文档 呢 ? 字段 名 总 是 已 知 的 时 候 最 适合 了 。 


例如 ， 假 设 我 们 要 了 解 玩 家 的 属性 ， 包 括 力量 (str), WH (int), A (wis), 
敏捷 (dex), HER (con) 和 魅力 (cha)。 此 时 ， 我们 总 是 明确 地 知道 要 查询 哪个 
属性 ， 所 以 可 以 这 样 设计 : 





{ 


n idt 4 "fired", 
"race" : "gnome", 
"Class" « “illusionist", 
"abilities" : { 

TEE € 20; 

tine" 2" 

twis" ; 18, 

"dex" : 24, 

taon" > 23; 
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要 查询 某 个 属性 时 ， 可 以 用 abilities.str， 和 abilities.con 之 类 的 查询 。 我 
们 绝 不 会 查找 哪个 属性 大 于 20， 总 是 会 知道 要 查 哪 个 属性 。 


1.10 技巧 10: 文档 要 自给 自足 


MongoDB 是 一 种 “无 脑 ” 的 大 型 数据 存储 。 也 就 是 说 ， MongoDB 几乎 不 做 任何 数 
据 处 理 ， 仅 仅 存 取 数 据 。 要 尽量 遵守 这 点 ， 避 免 让 MongoDB 做 些 能 在 客户 端 完 
的 计算 。 即 便 是 些 “ 小 ”任务 ， 像 求 平均 值 或 求 和 ， 也 要 放 在 客户 端 去 做 。 


如 果 要 找 的 信息 必须 经 过 计算 ， 且 无 法 直接 从 文档 中 获得 ， 有 两 种 方式 : 


。 付出 高 昂 的 性 能 代价 〈 强 制 MongoDB 使 用 JavaScript 计算 ,参见 技巧 11) ; 
。 优化 文档 结构 ， pee 息 能 够 从 文档 中 直接 获得 。 


通常 ， 你 只 需 通 过 文档 直截了当 地 给 出 这 些 信息 


现在 假设 要 找到 侠 果 (apples) MAT (oranges) 总 数 为 30 的 文档 。 文 档 结 
构 如 下 : 




















_ia" 123 
apples 10 
oranges 5 


像 上 面 这 样 设 计 的 话 ， 查 询 总 数 的 任务 就 得 仰 仗 JavaScript 了 ， 结 果 会 非常 低 效 。 
但 是 可 以 在 文档 中 加 入 一 个 总 数 (total) FE: 








id" 123 
apples 10 
oranges 5 
total" 15 


apples 和 oranges 字段 变化 时 总 数 也 要 变化 : 


> db.food.update (criteria, 
... { “Sine” : { “apples” : 10, “oranges” : -2, “total” : 8}}) 
> db. food. findone () 
{ 
t idr q 123, 
"apples" +: 20, 





应 用 设计 技巧 | 77 


"oranges" : 3, 
"total = 23 


} 


如 果 不 太 确定 更 新 会 改变 什么 内 容 ， 情 况 就 会 变 得 复杂 。 例 如 ， 要 查询 水 果 的 种 类 ， 
但 是 不 知道 更 新 会 不 会 增加 新 品种 。 


假设 文档 如 下 : 
{ 
" id" : 123, 
"apples" * 20, 
"oranges © 3, 
"total" : 2 


} 


如 果 一 个 更 新 可 能 创建 新 的 字段 ， 也 可 能 不 创建 ， 品 种 总 数 该 不 该 增加 呢 ? 若是 创 
建 了 新 的 字段 ， 总 数 也 是 要 随 着 增加 的 : 








> db.food.update({"_id" : 123}, {"Sine" : {"banana" : 3, "total" : 1}}) 


相反 ， 如 果 banana 字段 已 经 有 了 ， 则 不 应 增加 总 数 。 但 是 客户 端 根本 无 从 知晓 其 
存在 与 否 

你 恐怕 已 经 猜 到 了 ， 有 两 种 解决 办 法 ， 一 种 快 但 不 保证 一 致 ， 另 一 种 慢 但 能 保证 一 
致 性 。 


快速 的 做 法 就 是 简单 选择 给 total 加 1 或 者 不 加 ， 然 后 让 应 用 在 客户 端 验证 实际 的 
总 数 。 可 以 做 一 个 一 直 在 后 台 运 行 的 批 处 理 任务 来 纠正 这 些 不 一 致 的 地 方 。 


如 果 应 用 时 间 不 紧 ， 可 以 用 fingandModify 来 “ 锁 ” 住 文档 OXE “locked” F 
段 ， 其 他 写 入 会 手动 检查 这 个 字段 )， 返 回 文档 ， 然 后 同时 对 文档 解锁 并 更 新 相应 的 
字段 和 total: 























> var result = db. runCommand ({"findAndModify" : "food", 
. "query" : {/* 其 他 条 件 */, "locked" : false}, 
. "update" : {"Sset" : {"locked" : true}}} 
> 
> if ("banana" in result.value) { 
. db.fruit.update(criteria, {"$set" : {"locked" : false}, 
"Sinc" : {"banana" : 3}}) 
... } else { 
. // 如 果 banana 不 存在 ， 则 将 total 值 递 增 
. db.fruit.update(criteria, {"$set" : {"locked" : false}, 
ee "Sinc" : {"banana" : 3, "total" : 1}} 
本 


究竟 是 用 哪 种 得 看 具体 情况 。 
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1.11 技巧 11: 优先 使 用 $ 操 作 符 


$ 操作 符 应 付 不 来 某 些 操作 。 但 是 对 于 绝 大 多 数 应 用 ， 让 文档 本 身 提 供 足 够 的 内 容 
可 以 极 大 地 简化 查询 的 复杂 度 。 然 而 ， 还 是 有 些 情 况 下 的 查询 不 能 用 $ 操作 符 表 达 。 
这 时 候 就 得 借助 JavaScript 了 ， 可 以 在 查询 中 使 用 swhere 子 句 来 执行 JavaScript 
代码 。 


查询 中 的 $where 对 应 一 个 JavaScript 函数 ， 该 函数 的 返回 值 为 true 或 者 
false( 表示 匹配 与 否 )。 要 是 想 查找 所 有 member [0] .age F member [1] .age 相 
等 的 文档 ， 可 以 这 样 操作 : 





> db.members.find({"Swhere" : function() { 
. return this.member[0].age == this.member[1] .age; 


-JH 
正如 预期 ，$where 为 查询 带 来 了 极 大 的 灵活 性 。 但 是 也 带 来 很 大 的 效率 问题 。 





1.11.1 深入 了 解 

Swhere 效率 不 高 是 因为 MongoDB 为 此 要 做 很 多 事情 。 对 于 普通 的 查询 (没有 
Swhere 的 查询 )， 客 户 端 将 查询 转换 成 BSON (http: Wwww.bsonspec.org)， 然 后 
发 送 给 数据 库 。MongoDB 中 的 数据 也 是 BSON 格式 ， 所 以 直接 比较 就 可 以 了 。 这 
种 查询 非常 高 效 。 

若是 非得 用 $swhere 不 可 ，MongoDB 就 得 将 集合 中 的 每 一 个 文档 都 转换 成 
JavaScript 对 象 ， 解 析 文 档 的 BSON 并 添加 它们 的 所 有 字段 到 JavaScript 对 象 中 。 然 
后 执行 JavaScript， 之 后 就 销毁 。 所 以 极其 消耗 时 间 和 资源 。 





1.11.2 ”提高 性 能 

swhere 在 必要 时 很 有 用 ,但 能 避免 应 尽量 避免 。 实 际 上 ， 如 果 查 询 中 有 很 多 
swhere， 说 明 应 该 重新 考虑 数据 库 设 计 是 否 合理 了 。 

若是 Swhere 确 有 必要 ， 可 以 减少 swhere 要 匹配 文档 的 数量 来 缓解 性 能 损失 。 设 
置 一 些 不 用 Swhere 就 能 执行 的 查询 条 件 ， 并 将 其 放 在 最 前 面 。 Swhere 遍历 的 文档 
越 少 ， 需 要 的 时 间 就 越 少 。 

还 是 使 用 上 面 的 例子 ， 既 然 要 查看 会 员 的 年 龄 ， 那 么 必须 得 是 多 人 会 员 (Joint), 
比如 家 庭 会 员 (family) : 











> db.members.find({'type' : {$in : ['joint', 'family']}, 
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. "Swhere" : function() { 
return this.member[0].age == this.member[1] .age; 


ane 
这 样 单 人 会 员 就 不 在 Swhere 遍历 范围 内 了 。 


1.12 #41512: 随时 聚合 
要 尽 可 能 用 sinc 随时 计算 聚合 。 例 如 技巧 7 中， 分析 程序 要 有 按 分 钟 和 按 小 时 的 
统计 数据 。 增 加 按 分 钟 统计 的 数据 时 ， 同 时 可 以 增加 按 小 时 统计 的 数据 。 


如 果 聚 合 需要 进一步 的 计算 (比如 ， 计 算 每 小 时 的 平均 查询 次 数 )， 就 要 将 数据 存放 
到 分 钟 字段 中 ， 然 后 由 后 台 的 批 处 理 按 分 钟 字段 中 的 最 新 数据 计算 平均 值 。 由 于 所 
有 需要 聚合 的 信息 都 在 一 个 文档 中 ， 对 较 新 的 〈 未 聚合 的 ) 文档 ， 甚 至 可 以 把 计算 
放 到 客户 端 。 至 于 旧 文 档 ， 应 该 都 通过 批 处 理 计算 完了 。 


1.13 技巧 13: 编写 代码 处 理 数据 完整 性 问题 


由 于 MongoDB 无 模式 的 特点 和 反 范 式 化 的 优势 ， 你 需要 注意 应 用 数据 的 一 致 性 


问题 o 


很 多 ODM ' 有 多 种 方法 来 确保 不 同 级 别 的 一 致 性 。 然 而 ， 还 是 会 有 一 致 性 问题 ， 如 
由 于 系统 崩 涡 导致 的 数据 不 一 致 ( 技 巧 1)， 由 于 MongoDB 更 新 的 限制 导致 的 不 一 
Be (技巧 10)。 要 处 理 这 些 不 一 致 ， 要 有 个 脚本 做 数据 验证 。 


按照 本 章 的 建议 ， 可 能 要 有 几 个 cron 任务 ， 这 取决 于 具体 的 应 用 ， 如 下 所 示 。 


一 致 性 修复 器 











核对 计算 ， 检 查 重 复数 据 ， 确 保 数据 一 致 性 。 
预 分 配器 

创建 今后 要 用 到 的 文档 。 

聚合 器 

更 新 文档 内 部 的 聚合 数据 ， 使 之 为 最 新 数据 。 
其 他 有 用 的 脚本 〈《 和 本 章 联系 不 太 紧 密 ) 如 下 。 





PREL: 对 象 文档 映射 ， 类 似 于 关系 型 数据 库 的 ORM。 
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结构 校 验 器 

确保 当前 所 用 的 文档 都 有 指定 的 字段 ， 否 则 就 自动 校正 或 者 发 送 通知 。 
备份 任务 

定期 对 数据 库 做 fsync、 加 锁 和 导出 操作 。 

在 后 台 执 行 一 些 检查 和 保护 数据 的 脚本 ， 能 解除 很 多 后 顾 之 忧 。 
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实现 技巧 


2.1 技巧 14: 使 用 正确 的 类 型 


用 正确 的 类 型 存放 数据 大 有 神 益 。 数 据 类 型 影响 数据 的 查询 方式 、MongoDB 的 数 
据 存放 顺序 ， 以 及 占用 多 少 空间 。 


作为 数字 使 用 的 字段 都 应 该 作为 数字 存储 。 也 就 是 要 做 计算 或 者 按 大 小 排序 的 字段 。 
但 是 ， 用 哪 种 数字 呢 ? 有 时 无 所 谓 ， 有 时 则 要 慎重 考虑 。 

按 大 小 排序 所 有 数字 类 型 都 没 问题 。 比 如 把 一 个 32 位 整数 2、64 位 整数 1 和 一 个 
双 精 度 浮 点 数 (64 位 浮 点 数 ) 1.5 排序 ， 不 会 有 任何 问题 。 但 是 一 些 特定 操作 需要 
数据 为 某 些 特定 类 型 ， 如 位 操作 (AND 和 OR) 只 适用 于 整数 (不 能 是 双 精 度 浮 
点 数 )。 

数据 库 会 自动 转换 溢出 的 (比如 由 于 sinc 操作 导致 的 溢出 ) 32 位 浮 点 数 ， 将 其 变 
成 64 位 整数 ， 所 以 不 必 多 虑 。 








日 期 


和 数字 类 似 ， 是 精确 的 日 期 就 要 存 成 日 期 的 类 型 。 但 是 ， 有 些 日 期 (比如 生日 ) 并 
不 是 很 精确 ， 谁 也 不 会 知道 自己 出 生 时 间 的 毫秒 数 。 诸 如 此 类 的 日 期 用 ISO 格式 
的 日 期 就 好 了 ， 也 就 是 yyyy-mm-dd 形式 的 字符 串 。 这 样 对 生日 排序 也 不 会 有 问题 ， 
用 起 来 更 方便 ， 而 使 用 date 类 型 总 会 要 求 匹配 到 毫秒 级 别 。 





FHF 


MongoDB 中 的 字符 串 都 是 UTF-8 编码 的 ， 所 以 其 他 编码 形式 的 字符 串 必 须要 么 转 
换 成 UTF-8 编码 ， 要 么 以 二 进 制 形式 存储 。 





ObjectIda 

Objectid 就 要 作为 objectiIada 存 储 ， 千 万 不 要 存 成 字符 串 。 这 点 非常 重要 ， 原 因 
如 下 。 第 一 ,方便 查询 (字符 串 和 objectIa 不 能 相互 匹配 )。 第 二 ，objectIa 含 
有 有 用 的 信息 ， 绝 大 多 数 驱 动 都 有 方法 从 objectid 中 获知 文档 的 创建 日 期 。 第 三 ， 
字符 串 表 示 的 Objectia 要 多 占 两 倍 磁盘 空间 。 


2.2 技巧 15: 用 简单 唯一 的 1iq 蔡 换 id 
要 是 数据 本 身 没有 一 个 唯一 的 字段 (通常 就 是 这 样 ) ， 那 么 就 用 默认 的 objectid fF 
为 _id。 但 是 ， 若 是 数据 本 身 就 有 唯一 的 字段 ， 并 且 不 需要 objectId 的 功能 ， 那 
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么 就 用 自己 唯 一 的 值 覆 盖 掉 默认 的 _id 好 了 。 这 样 会 节省 一 些 空间 ， 尤 其 是 要 对 该 
字段 创建 唯一 索引 时 ， 就 会 省 下 一 个 索引 的 空间 和 资源 (非常 显 著 的 节约 )。， 


使 用 自 定义 的 _iad 还 有 些 商 端 。 第 一 ， 要 确保 其 唯一 性 ， 并 且 要 处 理 键 值 重 复 异 
常 。 第 二 ， 要 留意 索引 的 树 结 构 (技巧 22) , 要 清楚 随机 和 非 随 机 的 插入 顺序 会 怎 
样 。 就 索引 树 而 言 ，0bjectId 的 插入 顺序 非常 好 ， 因 为 它 的 值 总 是 增加 的 ， 所 以 
插入 总 是 在 B 树 的 右 侧 边 上 进行 。 这 样 MongoDB 只 需要 将 B 树 的 右 侧 边 放 在 内 存 
中 就 可 以 了 。 

与 之 相反 ，_id 中 随机 的 值 会 导致 在 整个 树 上 插入 。 这 样 系统 就 必须 将 对 应 的 索引 
页 面 调 入 内 存 ， 更 新 一 点 点 ， 然 后 就 可 能 放 之 不 管 ， 直 到 它 被 系统 移出 内 存 。 这 样 


效率 不 高 。 


2.3 技巧 16: 不 要 用 文档 做 _ia 


除了 不 可 避免 的 情况 (如 MapReduce 的 输出 ) ， 通 常 都 不 应 该 将 文档 作为 ia。 问 
题 就 在 于 索引 一 个 文档 中 的 字段 和 索引 文档 完全 不 一 样 ， 如 果 没 有 每 次 查询 整个 子 
文档 的 计划 ， 最 后 会 有 多 个 索引 ， 如 id, id.foo、 id.bar 等。 


更 改 id 必须 得 覆盖 整个 文档 ， 所 以 若 子 文档 的 字段 有 变化 则 更 新 非常 不 便 。 


2.4 技巧 17: 不 要 用 数据 库 引用 



































这 个 技巧 特 指 子 文档 形式 的 数据 库 引 用 ， 不 是 通常 意义 的 引用 (如 前 一 章 
Sia. 所 述 )。 


Os, 








数据 库 引 用 一 般 是 形 如 (Sid : identifier, $ref : collectionName} (也 可 
以 有 可 选 的 sdb 字段 ， 表 示 数 据 库 名 ) 的 常见 子 文档 。 这 有 点 像 关 系 型 数据 库 ， 引 
用 了 另 一 个 集合 中 的 文档 。 但 是 ， 并 不 是 真正 引用 了 其 他 集合 ， 仅 仅 是 一 个 普通 的 
子 文档 。 完 全 没有 什么 神奇 之 处 。MongoDB 也 不 能 在 必要 的 时 候 即 时 解除 数据 库 
引用 。MongoDB 也 不 用 这 种 方式 做 联结 。 它 们 只 是 存放 了 ia 和 集合 名 的 普通 子 
文档 。 也 就 是 说 为 了 解除 数据 库 引 用 必须 要 对 数据 库 额 外 做 一 次 查询 。 


若 被 引用 文档 的 集合 是 确定 的 ， 不 妨 只 用 _ia 引用 ， 这 样 比 同时 用 ia 和 集合 名 要 
节省 空间 。 如 果 知 道 要 引用 的 集合 ， 数 据 库 引用 就 显得 有 些 浪 费 空 间 。 




















译注 1: _id 自 带 了 唯一 索引 ， 且 不 可 取消 。 
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我 只 昕 说 过 一 次 数据 库 引 用 产生 了 积极 地 效果 ， 那 个 系统 中 的 用 户 可 以 评论 系统 中 
的 任何 事情 。comments 集合 中 存储 着 数据 库 引 用 ， 这 些 引 用 几乎 覆盖 了 系统 的 每 


个 角落 。 


2.5 技巧 18: 不 要 用 GridFS 处 理 小 的 二 进 制 数 据 


GridFS 需要 查询 两 次 ， 一 次 获取 文件 的 元 信息 ， 另 一 次 获取 其 内 容 (图 2-1)。 所 以 
如 果 用 GridFS 存储 小 文件 ， 会 使 应 用 查询 次 数 加 倍 。 从 根本 上 说 ，GridFS 是 用 来 


将 大 的 二 进 制 对 象 切 成 小 片 存 放 到 数据 库 中 。 








fs.files 
_id:x 
filename:.. | 
mdse 
fs.chunks 


ry 


(T 














2-1: GridFS 将 大 数据 分 成 小 块 存储 


GridFS 是 用 来 存放 大 数据 的 一 一 至 少 得 是 一 个 文档 放 不 下 的 数据 。 根 据 经 验 来 讲 ， 
因为 过 大 而 使 客户 端 一 次 加 载 不 了 的 东西 一 般 也 不 需要 服务 端 一 次 加 载 。 所 以 ， 那 
些 可 以 作为 数据 流传 递 给 客户 端的 数据 非常 适合 应 用 GridFS。 需 要 在 客户 端 一 次 全 
部 加 载 的 东西 ， 如 图 片 、 声 音 ， 甚 至 小 的 视频 ， 通 常 都 应 该 菊 到 主 文档 中 。 














延伸 阅读 : 


。 GridFS 机 理 (http:/www.mongodb.org/display/DOCS/GridFS ) 。 
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2.6 技巧 19: 处 理 “ 无 缝 ” 故 障 切 换 


人 们 经 常 听 到 MongoDB 可 以 做 无 颖 的 故障 切换 ， 所 以 当 遇 到 异常 就 会 非常 惊讶 。 
MongoDB 不 需要 干预 就 会 尝试 进行 故障 恢复 ， 但 是 有 些 特定 错误 是 它 无 法 自动 处 
理 的 。 


假设 发 送 给 服务 器 一 个 请 求 ， 得 到 了 网 络 错误 。 这 时 驱动 有 很 多 选择 。 


苔 驱动 不 能 重 连 数据 库 ， 显 然 束 不 能 重新 尝试 发 送 请 求 。 但 是 ， 若 驱动 知道 有 另 
一 台 服 务 器 ， 它 可 以 自动 对 甚 发送 请 求 吗 ? 这 要 看 到 底 是 什么 样 的 请 求 。 如 果 是 
对 活跃 节点 的 写 人 人， 可 能 没有 别 的 活跃 节点 了 。 要 是 读 取 ， 比 如 需要 执行 很 久 的 
MapReduce 操作 ， 本 来 执行 任务 的 从 属 市 点 出 故障 了 ， 驱 动 也 不 应 该 转发 请 求 到 随 
便 选 的 其 他 服务 器 (万 一 是 活跃 市 点 呢 ?)。 所 以 ， 对 另 一 台 服 务 器 不 能 自动 重 试 。 


要 是 错误 仅仅 是 临时 的 网 络 错误 ， 且 驱动 立刻 重新 获得 了 服务 器 的 网 络 连接 ， 它 也 
不 应 该 重新 发 送 请 求 。 要 是 驱动 发 送 原始 请 求 后 发 生 网 络 故障 ， 或 者 在 服务 器 响应 
的 时 候 发 生 故障 该 怎么 办 ? 数据 库 可 能 已 经 处 理 了 请 求 ， 所 以 不 必 再 次 发 送 。 


这 个 令 人 头痛 的 问题 总 是 和 应 用 相关 ， 所 以 驱动 将 问题 推 给 了 使 用 者 。 用 户 必须 要 
处 理 网 络 异 常 〈 详 见 驱动 文档 ) 。 处 理 异 常 ， 然 后 逐 请 求 地 判断 要 重新 发 送 请 求 吗 ， 
要 先 确 定数 据 库 状态 吗 ， 可 以 直接 放弃 吗 ， 还 是 需要 继续 重 试 ? 


2.7 技巧 20: 处 理 复制 组 失效 及 故障 恢复 
应 用 要 能 处 理 所 有 复制 组 会 遇 到 的 极端 情况 。 


假设 应 用 抛 出 了 “not master” 蜡 常 。 可 能 有 几 个 原因 : 复制 组 正在 做 故障 恢复 ， 应 
用 必须 要 平滑 地 应 对 活跃 节点 选举 的 这 段 时 间 。 选 举 的 时 间 不 尽 相 同 ， 一 般 只 需要 
几 秒 钟 ， 但 也 有 超过 30 秒 的 时 候 。 若 是 被 分 割 到 了 网 络 上 状况 不 佳 的 一 部 分 ， 可 能 
数 小 时 都 连 不 上 主 节 点 。 


看 不 到 主 节 点 是 要 重点 处 理 的 情况 ， 如 果 遇 到 了 这 种 情况 ， 你 的 应 用 能 降级 为 只 读 
模式 吗 ? 应 用 要 能 应 对 短 时 〈 活 跃 节点 选举 ) 只 读 和 长 时 (大 部 分 机 器 宕 机 或 者 网 


RRR) 只 读 。 
无 论 有 没有 活跃 节点 ， 都 应 该 能 继续 从 能 连接 的 节点 读 取 数据 。 


市 点 在 选举 期 间 会 进入 短暂 的 不 可 读 的 “恢复 ”阶段 ， 驱 动 若是 请 求 读 取 处 于 这 种 
状态 的 节点 ， 则 这 些 节 点 会 抛 出 错误 表明 自己 “ 既 不 是 主 节 点 也 不 是 从 属 节 点 "。 这 
种 状态 也 可 能 非常 短暂 ， 以 至 于 就 被 驱动 发 送 给 数据 库 的 两 次 ping 错过 了 。 
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编写 应 用 的 人 通常 都 希望 数据 库 能 即时 响应 。 为 了 使 应 用 尽 可 能 做 到 这 点 ， 就 必须 
要 知道 什么 最 耗 时 间 。 


3.1 技巧 21: 尽 可 能 减少 磁盘 访问 

内 存 访 问 比 磁盘 访问 要 快 得 多 。 所 以 ， 很 多 优化 的 本 质 就 是 尽 可 能 地 减少 对 磁盘 的 
访问 。 

模糊 数学 

内 存 的 读 取 速度 比 磁 盘 快 一 百 万 倍 。 

比方 说 通过 机 械 硬盘 访问 数据 要 10 毫秒 ， 而 内 存 访问 只 要 10 秒 。( 这 在 很 大 程度 上 
取决 于 硬 和 欠 和 内 存 的 种 类 ， 此 处 只 是 笼统 的 说 法 ， 力 求 给 和 人 一 个 大 致 的 印象 。) 对 应 


的 时 间 比 值 就 是 1 毫秒 比 1 纳 秒 。1 毫秒 等 于 100 万 纳 秒 ， 所 以 磁盘 访问 时 间 要 比 
内 存 长 大 约 一 百 万 倍 。 


所 以 从 计算 结果 得 知 ， 读 磁盘 要 消耗 很 长 时 间 。 
































We, 查看 连续 磁盘 访问 的 信息 。 但 不 会 很 精确 ， 因 为 MongoDB 还 有 些 非 连续 
的 读 写 ， 不 过 看 看 机 器 能 做 什么 也 挺 有 趣 的 。 





ee 在 Linux 中 ， 我 们 可 以 通过 运行 sudo hdparm -t /dev/hdwhatever Æ 
a 
4 





那么 ， 究 竟 该 如 何 应 对 呢 ? 有 几 种 “简单 ”的 办 法 。 
使 用 SSD 














SSD (固态 硬盘 ) 在 很 多 情况 下 都 比 机 械 硬盘 快 很 多 ， 但 容量 小 ， 价 钱 高 ， 难 以 安 
全 清除 数据 ， 与 内 存 读 取 速度 的 差距 依旧 明显 。 但 是 ， 还 是 可 以 尝试 用 用 的 。 一 般 
来 说 SSD 与 MongoDB 配合 得 非常 完美 ， 但 也 不 是 一 定 见 效 的 灵丹妙药 。 


增加 内 存 


增加 内 存 可 以 减少 对 硬盘 的 读 取 。 但 是 ， 增 加 内 存 也 只 能 解决 燃眉之急 ， 总 有 内 存 
装 不 下 数据 的 时 候 。 


所 以 ,问题 就 变 成 了 如 何在 磁盘 上 存放 太 字 市 级 别 ( 拍 字 市 级 别 ?) 的 数据 ， 而 同 
时 让 应 用 尽 可 能 只 读 取 在 内 存 中 的 数据 ， 又 尽量 避免 磁盘 和 内 存 之 间 的 数据 移动 。 


若 要 真正 实时 且 随 机 地 访问 数据 ， 就 只 能 仰赖 大 量 内 存 了 。 但 是 绝 大 多 数 应 用 并 不 
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EI, Dalal er Bie bee Be Em, EA te HA EDER, Ree Da 
其 他 地 方 拥有 更 多 的 客户 。 这 类 应 用 可 以 通过 精心 设计 ， 让 一 部 分 文档 在 内 存 中 ， 
极 大 减少 硬盘 访问 。 


3.2 技巧 22: 使 用 索引 减少 内 存 占用 


首先 ， 看 看 图 3-1， 其 中 展示 的 是 读 请 求 的 处 理 顺 序 。 























比较 文档 与 查询 


v 


i No. 有 匹配 吗 ? 


市 Yes 


+ Yes 














B 3-1: 对 数据 库 请 求 的 过 程 
本 书 中 假设 内 存 页 面 大 小 为 4KB ， 当 然 实际 中 并 不 总 是 如 此 。 


假设 机 器 共有 256 GB 的 数据 ，16 GB 的 内 存 ， 并 且 几 乎 所 有 数据 都 在 一 个 集合 上 ， 
现在 要 查询 这 个 集合 。MongoDB 会 如 何 处 理 呢 ? 


MongoDB 将 文档 的 第 一 个 页 面 加载 到 内 存 并 与 查询 比较 。 然 后 加 载 下 一 页 并 比较 。 
如 此 往复 ， 直 至 比较 完全 部 数据 。 没 有 捷径 可 循 ， 不 瞧 一 瞧 文 档 怎么 能 得 知 到 底 能 
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不 能 匹配 呢 ? 所 以 必须 要 遍历 整个 集合 。 因 此 ， 需 要 全 部 加 载 256 GB 数据 到 内 存 
( 当 需 要 空间 时 操作 系统 会 自动 将 旧 的 页 面 换 出 去 ) 。 整 个 过 程 相当 漫长 。 


怎样 避免 每 次 查询 都 加 载 全 部 数据 的 情况 呢 ? 可 以 让 MongoDB 对 指定 的 字段 x 创 
ERI. MongoDB 会 创建 相应 的 树 ， 大 体 上 预 处 理 这 些 数据 ， 并 将 这 一 集合 中 的 
每 个 x 值 都 添加 到 有 序 树 中 (参见 图 3-2)。 树 中 每 个 索引 项 都 含有 x 的 值 和 一 个 指 
向 对 应 文档 的 指针 。 树 中 只 有 指向 文档 的 指针 ， 而 不 是 文档 本 身 ， 也 就 是 说 索引 要 
比 整 个 集合 小 很 多 。 








v 
11 


| EN es 


图 3-2: B 树 ， 可 能 对 应 一 个 整数 字段 的 索引 


当 查 询 条 件 中 有 x，MongoDB 会 发 现 并 利用 x 的 索引 。 这 样 就 不 必 查 找 每 个 文档 ， 
MongoDB 会 这 样 判断 :“ 我 要 找 的 值 大 于 还 是 小 于 树 中 当前 节点 的 值 ? AKF, N 
去 右 侧 ， 若 小 于 ， 则 去 左 侧 。” 如 此 往复 ， 直 到 找到 欲 查 询 的 值 或 者 发 现 其 不 存在 。 
若是 找到 了 相应 值 ， 则 按照 对 应 的 指针 把 文档 页 面 加 载 到 内 存 ， 并 返回 结果 (参见 
图 3-3). 
































图 3-3: 索引 项 包含 索 35| 的 值 和 到 对 应 文档 的 指针 


所 以 ， 假 设 查询 能 在 集合 中 找到 一 两 个 匹配 的 文档 。 不 用 索引 的 话 ， 我 们 必须 把 
64 000 000 个 页 面 从 硬盘 加 载 到 内 存 。 





页 面 : 256 GB/ (4 KB/ 页 面 ) = 64 000 000 页 面 
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若是 索引 有 80GB, ， 则 索引 有 20 000 000 页 面 。 
页 面 : 80 GB / (4 KB/ 页 面 ) = 20 000 000 页 面 


另外 ， 索 引 是 有 序 的 ， 所 以 不 必 遍 历 全 部 项 ， 只 要 加 载 其 中 的 一 部 分 节点 就 可 以 了 。 
有 多 少 呢 ? 


要 加 载 进 内 存 的 页 面 : ln(20 000 000) = 17 页 面 
注意 ，64 000 000 竟然 减少 到 了 17! 


诚然 ，17 并 不 准确 ， 找 到 索引 中 的 结果 后 还 要 把 文档 加 载 到 内 存 ， 所 以 文档 大 小 也 
得 计算 在 内 ， 另 外 树 中 的 节点 也 可 能 超过 一 个 页 面 大 小 ， 也 要 额外 计算 。 但 不 管 怎 
么 说 ， 页 面 的 总 数 与 遍历 整个 集合 比 起 来 还 是 微不足道 的 。 


希望 大 家 现在 对 索引 加 速 查 询 的 机 理 有 个 大 概 的 认识 了 。 


3.3 技巧 23: 不 要 到 处 使 用 索引 


上 面 的 介绍 使 你 惊叹 于 索引 的 强大 作用 ,但 要 提醒 你 ， 不 是 所 有 查询 都 可 以 用 索引 
的 。 比 如 ， 在 刚才 的 例子 中 ， 要 是 需要 返回 集合 中 90% 的 文档 而 非 获取 一 些 记录 ， 
就 不 应 该 用 索引 。 


如 果 对 这 种 查询 用 了 索引 ， 结 果 就 是 几乎 遍历 整个 索引 树 ， 把 其 中 一 部 分 ， 比 方 说 
60 GB 的 索引 都 加 载 到 内 存 。 然 后 按照 索引 中 的 指针 加 载 集合 中 230 GB 的 文档 数 
据 。 最 终 将 加 载 230 GB + 60 GB =290 GB， 比 不 用 索引 还 多 。 


所 以 ， 索引 一 般 用 在 返回 结果 只 是 总 体 数据 的 一 小 部 分 的 时 候 。 根 据 经 验 ， 一 旦 要 
大 约 返 回 集合 一 半 的 数据 就 不 要 使 用 索引 了 。 

若是 已 经 对 茶 个 字段 建立 了 索引 ， 叉 想 在 大 规模 查询 时 不 使 用 它 (因为 使 用 索引 可 能 
会 较 低 效 )， 可 以 使 用 自然 排序 ， 用 {"$natural" : 1} 来 强制 MongoDB 禁用 索引 。 
自然 排序 就 是 “按照 磁盘 上 的 存储 顺序 返回 数据 *"， 这 样 MongoDB 就 不 会 使 用 索引 了 : 

















> db.foo.find().sort({"Snatural" : 1}) 


如 果 某 个 查询 不 用 索引 ，MongoDB 会 做 全 表 扫 描 ， 即 逐个 扫描 文档 ， 遍 历 整 个 集 
合 ， 以 找到 结果 。 


写 入 速度 
每 当 增加 、 删 除 、 更 新 记录 ， 所 有 相应 的 索引 也 必须 更 新 。 插 入 文档 时 ，MongoDB 
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需要 找到 文档 中 的 值 在 每 一 个 索引 树 中 的 位 置 ， 然 后 在 那儿 插入 。 删 除 时 ， 要 找到 
树 中 的 索引 项 并 删除 。 更 新 时 ， 也 可 能 像 插入 时 那样 新 建 索 引 项 ， 也 可 能 像 删 除 时 
那样 删除 索引 项 ， 者 是 值 更 新 了 就 会 姨 有 添加 又 有 删除 。 所 以 ， 索 引 会 增加 很 多 额 
外 的 写 入 。 


3.4 技巧 24: 索引 覆盖 查询 

如 果 只 想 返 回 某 些 字 段 且 所 有 这 些 字 段 都 可 放 在 索引 中 ，MongoDB TURSI A 
盖 查 询 (covered index query)， 这 种 查询 不 会 访问 指针 指向 的 文档 ， 而 是 直接 用 索 
引 的 数据 返回 结果 。 比 如 ， 有 如 下 索引 : 

















> db.foo.ensureIndex({"x" : 1, "y" : 1, "z" : 1}) 


现在 查询 被 索引 的 字段 ， 并 只 要 求 返 回 这 些 字段 ，MongoDB 就 没 必要 加 载 整个 文档 : 





> db.foo.find({"x" : criteria, "y" ; criteria}, 
A {meer 22, ty" dy tat o p id" : 0}) 


这 样 查询 仅仅 访问 了 索引 的 数据 ， 而 没有 访问 整个 集合 的 数据 。 
注意 结果 子 句 "id":0，_ ia 是 默认 返回 的 ， 但 不 是 上 面 索引 的 一 部 分 ， 所 以 


MongoDB 就 需要 到 文档 中 获取 ia, HHA, MongoDB 就 可 以 仅 根据 索引 返 
结果 了 。 


若是 查询 只 返回 儿 个 字段 ， 则 考虑 将 其 放 到 索引 中 ， 即 使 不 对 它们 执行 查询 ， 也 能 
做 索引 覆盖 查询 。 例 如 ， 上 面 的 查询 中 并 没有 用 到 z， 但 是 是 个 要 返回 的 字段 ， 所 
以 放 到 了 索引 中 。 


3.5 技巧 25: 使 用 复合 索引 加 快 多 个 查询 


若 有 可 能 ， 要 建立 能 被 多 个 查询 利用 的 复合 索引 。 这 未 必 能 实现 ， 但 当 多 个 查询 的 
参数 相似 时 就 有 机 会 。 


查询 只 要 和 索引 开头 部 分 匹配 就 能 利用 索引 。 所 以 ， 建 立 索 引 时 要 考虑 这 些 查询 依 
赖 的 所 有 字段 。 


假设 应 用 需要 执行 这 些 查询 : 


El 











collection.find({"x" : criteria, "y" = criteria, "z" p criteria}) 
collection.find({"z" : criteria, "y" : criteria, "w" : criteria}) 
collection.find({"y" : criteria, "w" = criteria}) 
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可 以 看 到 ，y 字段 是 唯一 一 个 每 个 查询 都 有 的 ， 所 以 很 适合 放 到 索引 中 去 。z 在 前 
两 个 中 出 现 了 ，w 在 后 两 个 中 出 现 了 ， 因 此 它们 两 个 都 是 仅 次 于 y 字段 的 合适 选项 
(索引 排序 详 见 技巧 27 以 及 技巧 28 ) 。 


索引 的 命中 率 越 高 越 好 。 某 个 查询 如 果 更 重要 或 者 执行 更 频繁 的 话 ， 索 引 也 要 针对 
它 进行 优化 。 例 如 ， 假 设 第 一 个 查询 的 执行 次 数 是 后 两 个 的 数 千 倍 ， 则 选择 对 其 建 
立 索 引 : 








collection.ensureIndex({"y" : 1, "z" : 1, "x" : 1}) 

这 样 就 是 针对 第 一 个 查询 尽 可 能 做 了 优化 ， 后 两 个 查询 能 部 分 利用 这 个 索引 。 

个 查询 执行 的 情况 大 体 相当 ， 下 面 的 索引 则 更 佳 : 
collection.ensureIndex({"y" : 1, "w" : 1, "z" : 1}) 


这 样 3 个 查询 都 能 利用 索引 做 y 条 件 的 查询 ， 后 两 个 查询 能 用 到 w 的 部 分 ， 中 间 的 
查询 则 可 以 完全 利用 这 个 索引 。 


可 以 用 explain 来 查看 查询 中 是 如 何 使 用 索引 的 : 





collection.find(criteria) .explain() 


3.6 #1526: 通过 建立 分 级 文档 加 速 扫描 


将 数据 组 织 得 有 层次 ， 不 仅 可 以 让 其 看 着 更 有 条 理 ,还 可 让 MongoDB 在 (偶尔) 
没有 索引 时 也 能 快速 查询 。 


例如 ， 假 设 有 个 查询 并 不 使 用 索引 。 如 前 文 所 述 ，MongoDB 需要 遍历 集合 中 的 所 
有 文档 ， 来 确定 是 否 有 什么 能 匹配 查询 条 件 。 这 个 过 程 可 能 相当 耗 时 ， 而 这 取决 于 
文档 结构 。 


比方 说 ， 用 户 文档 使 用 了 扁平 的 结构 : 
{ 





hs ee 
"name" : username, 
"email" : email, 
"twitter" : username, 
"Screenname" : username, 
"facebook" : username, 
"linkedin" : username, 
"phone" : number, 
"Street" : street, 
"city" : city, 
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“state” : state, 
"Zip" : zip, 
"fax" : number 


} 
假设 我 们 要 执行 下 面 的 查询 : 


> db.users.find({"zip" : "10003"}) 





MongoDB 会 做 哪些 工作 呢 ?” 它 必须 壳 历 每 个 文档 的 每 个 字段 ， 来 查找 zip 字段 


(图 3-4)。 












_id? nope. 
name? nope 
email? nope. .. 














B 3-4: 若 文 档 没 有 层次 的 话 ，MongoDB 必须 遍历 文档 中 的 每 个 字段 


使 用 内 艇 文档 我 们 可 以 建立 自己 的 “ 树 ”， 能 让 MongoDB 执行 比 此 查询 时 更 快 。 现 


在 结构 变 了 : 
w igr s id; 
"name" : username, 
"online" : { 
"email" : email, 
"twitter" : username, 
"Screenname" : username, 
"facebook" : username, 
"linkedin" : username, 
} ， 
"address" : { 
"street" ; street, 
Welty" > city, 
"State" : state, 
"zip" : zip 
} 
"tele" : { 
"phone" : number, 
"fax" : number, 
} 
} 
相应 地 查询 也 变 了 : 
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> db.users.find({"address.zip" : "10003"}) 


这 样 MongoDB 在 找到 匹配 的 address 之 前 ， 仅 查看 id, name 和 online, MiJa 
在 address 中 匹配 zip。 合 理 使 用 层次 可 以 减少 MongoDB 对 字段 的 访问 。 


3.7 ”技巧 27: AND 型 查询 要 点 


假设 要 查询 满足 条 件 A、B、C 的 文档 。 若 满足 A 的 文档 有 40 000, 满足 B 的 有 
9 000, WE C 的 有 200。 要 是 让 MongoDB 按照 这 个 顺序 查询 ， 效 率 可 不 高 (参见 
图 3-5)。 








AAA( 


DR 


图 3-5: 深 色 部 分 表示 每 步 都 必须 搜索 的 查询 空间 、 相 比较 而 言 ， 按 照 结 果 数 量 由 大 到 小 的 
顺序 进行 的 查询 多 做 了 好 多 


如 果 把 C 放 在 最 前 ， 然 后 是 B， 最 后 是 A， 则 针对 B 和 C 只 需要 查看 (最 多 ) 200 
个 文档 (图 3-6) 。 

















@ © A Q 


3-6: HRA C 放 在 最 前 面 ， 后 续 查 询 的 搜索 空间 将 明显 减少 


这 样 工 作 量 显著 减少 了 。 要 是 已 知 某 个 查询 条 件 更 加 苛 刻 ， 则 要 将 其 放置 在 最 前 面 
(尤其 是 在 它 有 对 应 索引 的 时 候 )。 


3.8 #1528: OR 型 查询 要 点 


OR 型 查询 与 AND 型 查询 正 相 反 ， 匹 配 最 多 的 查询 语句 应 该 放 在 最 前 面 ， 因 为 
MongoDB 每 次 都 要 匹配 不 在 结果 集中 的 文档 。 


若是 按照 AND 型 的 顺序 查询 ， 每 次 都 要 查询 很 多 文档 〈 图 3-7). 







































Ló |@& 


图 3-7: 矩形 表示 整个 集合 ， 深 色 部 分 表示 每 一 步 都 要 搜索 的 空间 。 若 先 按 C 进行 搜索 ， 则 
后 续 的 每 步 都 需要 查 绝 大 部 分 的 集合 


因此 ， 我 们 应 将 匹配 最 多 的 放 在 最 前 面 (图 3-8)。 


Wace 


3-8: 将 结果 最 多 的 条 件 前 置 能 缩小 后 续 查 询 的 搜索 空间 
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第 4 章 





数据 安全 性 和 一 致 性 


4.1 技巧 29: 单机 做 日 志 ， 多 机 则 复制 


理想 情况 下 ， 所 有 的 写 入 都 能 立刻 执行 并 永久 地 保留 在 磁盘 上 ， 可 以 被 立刻 访问 到 。 
可 惜 现 实情 况 并 不 是 这 样 ， 要 么 需 多 花 时 间 确 保 数 据 安全 ， 要 么 只 能 加 快速 度 但 使 
数据 不 怎么 安全 。 这 是 MongoDB 灵活 性 的 最 佳 体 现 ， 所 以 一 定 要 掌握 各 种 方法 。 


复制 和 日 志 是 MongoDB 确保 数据 安全 性 的 两 种 途径 。 

通常 都 要 使 用 复制 ， 而 且 至 少 要 有 一 台 服 务 器 启用 日 志 。MongoDB 博客 有 篇 很 棒 
的 文章 , 说 明了 为 什么 不 应 该 在 单个 服务 器 上 运行 MongoDB ( 别 的 数据 库 也 一 样 )。 
MongoDB 的 复制 自动 在 服务 器 间 同 步 写 入 操作 。 如 果 活 跃 节点 停机 ， 则 可 以 将 另 
一 台 服 务 器 选 作 主 市 点 (如果 用 了 复制 组 ， 这 个 过 程 就 是 自动 的 )。 


如 果 复 制 组 中 的 一 个 节点 没有 正常 停机 ， 也 没有 启动 --journal 选项 ，MongoDB 
并 不 能 保证 数据 安全 性 (数据 可 能 已 损坏 )。 所 以 得 有 一 份 和 干净 的 数据 ， 无 论 删 掉 
后 重新 同步 ， 还 是 加 载 备份 并 快速 同步 (http:/www.mongodb.org/display/DOCS/ 
Upgrading+to+Replica+Sets#UpgradingtoReplicaSets-UsingsSlave%27SExistingData ) 。 





























日 志 能 保证 单个 服务 器 的 数据 安全 。 所 有 操作 都 将 被 记录 下 来 〈 日 志 ) 并 定期 写 入 
磁盘 。 如 果 机 器 崩溃 了 ， 但 硬盘 还 是 好 的 ， 你 就 可 以 重启 服务 器 ， 数 据 会 自动 根据 
日 志 完 成 修复 。 记 住 要 是 硬件 出 了 问题 ，MongoDB 也 无 能 为 力 。 如 果 硬 盘 坏 了 ， 
数据 库 很 可 能 恢复 不 了 。 


虽然 复制 和 日 志 可 以 同时 使 用 ， 但 是 性 能 会 受到 影响 。 两 种 方式 都 会 将 所 有 写 和 人 进 
行 备份 ， 所 以 你 可 以 进行 如 下 选择 。 











无 安全 措施 

每 个 请 求 写 和 一次。 
复制 

每 个 请 求 写 入 两 次 。 
日 志 

每 个 请 求 写 入 两 次 。 
复制 + 日 志 


每 个 请 求 写 入 3 次 。 
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将 一 条 信息 写 入 3 次 确实 有 点 多 ,但 是 要 是 性 能 无 需 太 高 ， 恰 恰 数 据 安全 性 却 非常 
重要 ， 没 准 可 以 两 者 结合 使 用 。 后 面 会 讲 一 些 既 安全 又 更 高 效 的 方案 。 


4.2 #21530: 坚持 使 用 复制 或 日 志 , 或 两 者 兼用 


单一 服务 器 要 用 -- journal 选项 。 





开发 过 程 中 建议 一 直 开 着 - -journal 选项 。 在 本 地 MongoDB 配置 中 开 
SS 4 、 启 日 志 是 为 了 确保 开发 过 程 中 不 丢失 数据 。 














由 于 使 用 日 志 会 导致 性 能 下 降 ， 多 台 机 器 情况 下 可 以 混合 使 用 启用 日 志 的 和 不 启用 
日 志 的 服务 器 。 备 份 用 的 从 属 节点 可 以 用 日 志 ， 活 跃 节 点 和 热 备 节点 〈 尤 其 是 做 读 
取 负 载 均 衡 的 节点 ) 可 以 不 用 。 


图 4-1 展示 了 一 组 小 巧 健壮 的 设置 。 活 跃 节 点 和 热 备 节 点 都 没有 开局 日 志 ， 这 样 能 
够 快速 读 写 。 通 常 遇 到 服务 器 崩溃 时 ， 可 以 切换 到 热 备 节点 ， 然 后 有 空 的 时 候 再 来 
重启 坏 掉 的 服务 器 。 



































图 4-1: 活跃 节点 (P)、 热 备 节点 (S) 和 开启 日 志 的 备份 服务 器 


即便 其 中 一 个 数据 中 心 完 全 停止 运行 ， 数 据 依然 是 安全 的 ， 因 为 还 有 一 个 安全 的 数 
据 副 本 。DC2 停机 时 ， 如 果 又 重新 开始 运转 ， 还 是 重启 备份 服务 器 就 好 了 。 如 果 
DCI 停机 ， 可 以 将 备份 机 器 切换 成 主 节 点 ， 或 者 用 其 数据 恢复 DC1 的 机 器 。 就 算 
两 个 数据 中 心 都 停机 ， 至 少 DC2 的 备份 数据 能 让 我 们 用 于 引导 恢复 。 

图 4-2 展示 了 5 台 机 器 的 安全 设计 方案 。 这 个 方案 比 前 一 个 方案 更 可 靠 ， 两 个 数据 
中 心 都 有 热 备 节点 ， 还 有 一 个 加 了 时 间 延 迟 用 来 预防 用 户 误 操 作 ， 还 有 一 台 为 了 以 
防 万 一 启用 了 日 志 。 
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图 4-2: 一 个 活跃 节点 (P)， 两 个 热 备 节点 (S) 一 个 有 时 间 延 迟 的 从 属 节点 ， 以 及 一 个 开启 
日 志 的 备份 服务 器 (B) 


4.3 技巧 31: 不 要 信任 repair 恢 复 的 数据 


如 果 数 据 库 泪 了 ， 且 没有 启用 --journal 选项 ， 千 万 不 要 将 这 些 数 据 拿 来 就 用 。 
可 能 几 个 星期 都 平安 无 事 ， 但 突然 间 访 问 到 了 损坏 了 的 文档 ， 应 用 程序 就 遭 玖 了 。 
另外 ， 也 可 能 由 于 索引 的 混乱 导致 返回 的 结果 不 完整 ， 还 可 能 导致 其 他 诸多 问题 。 
崩 涡 导致 的 问题 比较 严重 ， 而 且 可 能 潜伏 且 通 常 很 长 一 段 时 间 都 不 能 被 发 现 。 




















当然 还 是 有 些 选 择 的 。 运 行 repair (http://www.mongodb.org/display/DOCS/ 
Durability+and+Repair#Durabil ityandRepair-RepairCommand) 是 一 种 诱 
人 的 做 法 ， 但 却 是 个 最 不 适当 的 选择 。 首 先 ， 这 个 过 程 要 遍历 所 有 能 找到 的 文档 并 
复制 。 这 个 过 程 极其 耗 时 ， 而 且 需 要 大 量 磁盘 空间 (至 少 与 现在 使 用 的 空间 相同 )， 
而 有 问题 的 文档 会 被 直接 忽略 掉 。 要 是 因为 崩溃 ， 数 以 万 计 的 文档 找 不 到 的 话 ， 就 
不 能 被 复制 ， 也 就 意味 着 丢失 了 。 数 据 库 是 正常 了 ， 但 数据 却 可 能 丢 很 多 。 此 外 ， 
repair 的 修复 也 是 有 限 的 ， 它 并 不 能 知晓 文档 的 细节 ， 所 以 若 骨 误导 致 其 些 字段 
无 法 解析 ， repair 是 无 法 发 现 或 修复 的 。 


我 们 比较 推荐 的 做 法 是 从 备份 快速 恢复 ,或 者 从 头 开始 同步 。 注 意 ， 在 同步 数据 之 
前 一 定 要 清除 所 有 损坏 的 数据 ，MongoDB 的 复制 是 不 能 修复 这 些 损毁 数据 的 。 














4.4 技巧 32: getlasterror 


默认 情况 下 ， 写 入 是 不 返回 任何 数据 库 响 应 的 。 也 就 是 说 车 发 送 给 数据 库 更 新 、 插 
入 、 删 除 这 样 的 指令 ， 数 据 库 在 执行 完成 后 不 返回 给 用 户 任何 确认 信息 。 所 以 ， 驱 
动 也 得 不 到 指令 是 否 成 功 执 行 的 响应 。 
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然而 ， 很 多 情况 下 需要 得 到 数据 库 的 响应 。 为 此 ，MongoDB 有 个 返回 上 一 个 指令 
执行 状态 的 命令 ， 叫 做 getlasterror。 起 初 ， 它 只 是 用 来 描述 上 一 个 指令 的 错误 
信息 ， 但 后 来 扩展 到 了 描述 各 种 写 和 信息 并 提供 了 一 系列 与 安全 性 相关 的 选项 。 








为 了 避免 “ 读 取 最 近 写 入 ”这 种 粗心 的 错误 〈 详 见 技 巧 S0) getlasterror 会 和 
写 入 请求 捆绑 在 一 块 ， 强 制 数据 库 将 两 者 作为 一 个 请 求 。 两 者 被 同时 发 送 并 确保 连 
续 执行 ， 期 间 没 有 任何 别 的 操作 。 驱 动 会 自动 处 理 这 些 ， 所 以 使 用 者 并 不 需要 特别 
留意 ， 就 把 它 当 做 “安全 ” 写 入 好 了 。 


A mo rh} mH 
45 #1533: 开发 过 程 中 一 定 要 使 用 安全 写 入 
开发 过 程 中 ， 你 都 会 希望 应 用 程序 的 行为 与 预期 一 致 ， 这 就 离 不 开 安全 写 入 了 。 写 
入 都 会 导致 哪些 错误 呢 ? 革 次 写 和 人 可 能 会 向 非 数 组 字段 push 数据 ， 导 致 键 重复 异常 
(试图 向 有 唯一 索引 的 字段 存放 两 个 值 相同 的 文档 ) ， 删 除 一 个 _ia 字 段 ， 否 则 会 有 
数 百 万 其 他 用 户 错误 。 部 署 之 前 需要 知道 这 些 写 和 人 是 否 合理 。 


耗 尽 磁盘 空间 也 是 不 太 容 易 被 发 现 的 错误 ， 比 如 突然 间 查 询 神秘 “丢失 ”了 一 些 数 
据 。 如 果 没 有 用 安全 写 入 ， 就 不 太 容 易 发 现 ， 因 为 一 般 你 也 不 会 想到 检查 磁盘 。 我 经 
常 将 --dbpath 设置 到 错误 的 分 区 ， 导 臻 MongoDB 耗 尽 磁盘 的 时 间 比 预期 早 得 多 。 


在 开发 过 程 中 ， 有 许 许 多 多 的 开发 错误 会 导致 号 人 失败 ， 这 些 都 是 需要 了 解 和 处 
理 的 。 


4.6 421534: 使 用 w 参 数 


有 些 重要 的 操作 ， 需 要 将 写 人 数据 复制 到 复制 组 的 大 多 数 节 点 。 直 到 大 多 数 节 点 都 
写 人 了 ， 写 人 才 算 提交 完成 。 若 是 写 入 未 能 提交 完成 ， 同 时 网 络 发 生 割 裂 或 者 服务 
器 由 于 故障 与 复制 组 的 多 数 市 点 失去 联络 ， 写 入 就 会 回 深 。( 题 外 话 ， 要 是 对 回 深 
感 兴趣 ， 大 家 可 以 参考 我 的 一 篇 博文 ， 其 中 讲述 了 如 何 操 作 ， 地 址 为 http://www. 
snailinaturtleneck.com/blog/2011/01/19/how-to-use-replica-set-rollbacks/。 ) 





























w 表 示 至 少 要 有 多 少 台 服务 器 写 入 了 才 返 回 成 功 。 过 程 也 简单 ， 不 过 是 发 送 
getlasterror 到 服务 器 (通常 就 是 针对 某 一 具体 的 写 操作 设置 w)。 服 务 器 清楚 
自己 在 oplog 中 的 位 置 (“在 123 号 操作 ”)， 然 后 等 待 w 一 1 个 节点 完成 123 号 
操作 。 每 当 有 从 属 节 点 完成 指定 操作 ,活跃 市 点 就 将 w 计 数 减 1。 一旦 w 等 于 0， 
getlasterror 就 返回 成 功 。 


注意 ， 复制 的 写 入 总 是 按照 一 定 次 序 进行 的 ， 不 同 的 市 点 可 能 处 在 不 同 的 “历史 位 
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置 ”， 但 数据 集 一 定 是 一 致 的 。 它 们 会 和 活跃 节点 一 分 钟 前 ， 也 可 能 是 几 秒 钟 前 ， 或 
一 周 以 前 等 完全 一 样 。 但 绝 不 会 丢失 任何 操作 。 


也 就 是 说 ， 以 下 命令 能 够 强制 num-1 个 节点 与 活跃 节点 同步 : 
> db.runCommand ({"getlasterror" =. 1, “wt ; num} ) 


所 以 ， 开 发 者 会 问 : 如 何 设置 w 呢 ? 前 面 提 到 过 ， 要 想 绝对 安全 就 得 大 于 节点 数 的 
一 半 。 然而 ， 小 于 半数 也 是 可 行 的 。 


w 如 果 小 于 服务 器 数 的 一 半 ， 则 更 易于 完成 ， 可 能 已 经 够 用 了 。 若 是 这 一 小 部 分 市 
点 由 于 网 络 割 裂 或 者 服务 器 故障 与 复制 组 失去 联系 ， 则 复制 组 中 另外 过 半数 的 节点 
会 选举 新 的 活跃 节点 ， 并 丢失 已 经 同步 到 w 个 节点 的 操作 。 然 而 ， 只 要 有 一 个 已 经 
同步 的 节点 与 复制 组 依然 保持 联系 ， 那 么 复制 组 中 的 其 他 节点 都 会 在 选举 新 活跃 闻 
点 前 同步 这 个 写 人 操作 。 


将 w 设 置 为 超过 服务 器 数目 的 一 半 ， 如 果 网 络 发 生 割 裂 或 者 某 些 服务 器 停止 运行 ， 
只 有 处 理 完 写 和 人 的 活跃 节点 才能 被 选举 。 这 个 条 件 为 数据 安全 提供 了 有 力 保障 ， 但 
不 太 好 达成 ， 因 为 需要 越 多 市 点 同步 ， 完 成 的 可 能 性 就 越 低 。 


4.7 技巧 35: 一 定 要 给 w 设 置 超时 


假设 有 一 个 含 3 个 节点 的 复制 组 〈 一 个 活跃 节点 和 两 个 热 备 节点 ) ， 现 在 要 做 两 个 从 
属 市 点 与 主 市 点 间 的 同步 : 





> db.runCommand({"getlasterror" : 1, "w" : 2}) 


但 要 是 有 个 热 备 节点 停机 了 怎么 办 ? MongoDB 不 会 检查 集群 内 热 备 节点 的 数量 ， 
它 会 等 待 w 个 从 属 节 点 复制 完成 ， 可 能 是 2 个 、20 个 或 者 200 个 〈 要 看 具体 的 w 


一 | 


所 以 ， 使 用 getlasterror 时 一 定 要 合理 设置 wtimeout 参数 。wtimeout 表示 从 
节点 报告 返回 并 失败 时 超时 等 待 的 毫秒 数 。 下 面 以 100 毫秒 为 例 : 


> db.runCommand({"getlasterror" : 1, "w" : 2, "wtimeout" : 100}) 


注意 MongoDB 应 用 复制 操作 的 顺序 。 如 果 将 A、B、C 写 入 到 主 节 点 ， 复 制 到 从 属 
节点 的 时 候 也 是 A、B、C 这 种 顺序 。 假 设 现在 的 情况 如 图 4-3 所 示 。 如 果 在 主 市 
点 上 写 入 N， 然 后 执行 getlasterror， 从 属 节 点 必须 将 E ~ N 都 复制 成 功 ， 而 后 
getlasterror 才能 返回 成 功 。 所 以 ， 如 果 从 属 节 点 的 复制 慢 了,，getlasterror 
会 使 应 用 运行 速度 变 得 很 慢 。 
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Master oplog: 


Slave oplog: 


B 4-3: 主 节点 和 从 属 节点 的 oplog。 与 活跃 节点 相 比 ， 从 属 节点 落后 了 10 个 操作 


还 有 一 件 事 儿 在 掌控 范围 内 ， 那 就 是 如 何 处 理 getlasterror 超时 。 显 然 ， 保 证 到 
另 一 服务 器 的 复制 是 因为 这 个 写 入 很 重要 。 但 要 是 写 入 本 地 没 问题 ,但 是 不 能 复制 
到 足够 的 备份 机 器 ， 该 怎么 办 呢 2 


4.8 #21536: 不 要 每 次 写 入 都 调用 fsync 


要 是 有 重要 的 数据 需 在 日 志 中 有 记录 ， 则 写 人 时 一 定 要 使 用 fsync 选项 。fsync 
会 等 待 数据 都 成 功 写 入 日 志 (至 多 100 毫秒 )， 然 后 才 会 返回 成 功 。 要 注意 的 是 ， 
Esync 并 不 是 立即 将 数据 写 入 磁盘 ， 而 是 让 应 用 程序 暂停 直至 数据 被 写 人 磁盘 。 所 
以 ， 若 每 次 插入 都 运行 fsync， 则 每 100 毫秒 只 能 插入 一 次 。 这 比 MongoDB 普通 
插入 不 知 慢 了 多 少 倍 ， 所 以 还 是 少 用 fsync 为 妙 。 


通常 fsync 只 与 日 志 搭 配 使 用 。 除 非特 别 清楚 ， 人 否则 绝 不 要 在 未 开启 日 志 时 使 用 fsync。 
不 听 忠 告 会 得 不 偿 失 ,严重 影响 应 用 性 能 的 。 


4.9 技巧 37: 朋 演 之 后 正常 启动 


如 果 开 启 了 日 志 ， 并 且 虽 然 崩 涡 ， 但 系统 可 以 恢复 (比如 硬盘 没有 受 损 ， 机 器 也 没有 
进 水 )， 数 据 库 可 以 正常 重启 。 注 意 使 用 常规 选项 ， 尤 其 是 --dbpath (以 便 找到 日 
志文 件 ) 和 --journal。MongoDB 会 自动 修复 数据 ， 而 后 才 开始 接受 连接 。 数 据 比 
较 多 时 这 可 能 会 需要 几 分 钟 ， 但 比 起 repair 要 省 很 多 时 间 了 (大 约 5 分 钟 左 右 ) 。 


日 志文 件 存 放 在 日 志 目 录 中 ， 千 万 不 要 删除 。 


4.10 技巧 38: 持久 性 服务 器 的 瞬时 备份 


备份 开启 日 志 的 数据 库 有 两 种 方法 , 其 一 就 直接 对 文件 系统 做 快照 ， 其 二 就 是 用 
fsync 和 锁 配 合 ， 然 后 导出 数据 。 注 意 不 能 没有 执行 fsync 和 上 锁 就 直接 复制 所 有 
文件 ， 因 为 文件 复制 不 能 瞬时 完成 。 若 复制 数据 库 和 日 志 的 时 间 点 不 同 ， 这 样 还 不 
如 不 备份 。( 一 旦 应 用 了 这 些 日 志 ， 就 有 可 能 破坏 数据 文件 。) 
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5.1 技巧 39: 手工 清理 块 集合 

GridFS 将 文件 内 容 保 存在 块 集合 中 ， 默 认 的 集合 名 是 fs.chunks。 文 件 集合 中 的 每 个 
文档 都 会 指向 块 集合 中 的 一 个 或 多 个 文档 。 所 以 经 常 要 检查 ， 看 看 有 没有 扳 悬 的 块 
(就 是 没有 和 文件 关联 的 块 )。 若 数据 库 在 保存 文件 的 过 程 中 异常 关机 ( 块 写 入 后 才 
会 写 fs.files 文档 ) ， 就 可 能 出 现 这 种 情况 。 


检查 块 集合 要 选择 流量 较 小 的 时 段 〈 因 为 会 往 内 存 中 调和 人 大 量 数据 ) ， 步 又 如 下 : 








> var cursor = db.fs.chunks.find({}, {"_id" : 1, "files id" : 1}); 
> while (cursor.hasNext()) { 
. var chunk = cursor.next(); 
. if (db.fs.files.findOne({_id : chunk.files_id}) == null) { 
print ("orphaned chunk: " + chunk. id); 


a 
APE AEH ATA RAY id 列 出 来 。 
在 删除 所 有 这 些 扳 大 的 块 之 前 ， 要 确保 其 不 是 正 被 写 人 文件 的 组 成 部 分 ! 你 应 当 用 


db.currentOp() 指令 取消 当前 操作 ， 之 后 看 看 fs.files 集合 查看 最 近 的 uploadDate 
(上 传 日 期 ) 。 


5.2 技巧 40: 用 repair 压 缩 数据 库 


技巧 31 中 讲 到 了 通常 不 建议 用 repair 去 恢复 数据 (除非 迫不得已 ) 的 原因 。 不 过 
repair 用 来 压缩 数据 倒是 正 合适 。， 

Ha 
但 愿 这 个 技巧 早 些 过 时 ， 和 希望 一 旦 在 线 压缩 的 bug 得 到 修正 就 不 需要 这 个 
技巧 了 。 (BW http://jira.mongodb.org/browse/SERVER-2120, ) 











a S, 
(er a 





repair 基本 上 就 是 mongodump 加 mongorestore, 通过 这 一 过 程 将 数据 都 整理 出 
来 ， 形 成 整洁 的 数据 副本 ， 移 除 文件 的 所 有 数据 碎片 。( 当 有 大 量 删 除 或 者 更 新 而 导 
致 数据 移动 ， 集 合 中 就 会 出 现 很 多 空洞 。) repair 会 以 压缩 形式 重新 插入 数据 。 


使 用 repair 还 有 些 注 意 事 项 。 


。 这 样 会 阻塞 操作 ， 所 以 不 要 在 活跃 节点 上 执行 。 一 般 先 在 热 备 闻 点 上 执行 ， 然 后 让 
活跃 节点 和 热 备 节点 交换 角色 ， 再 在 原来 的 活跃 节点 (现在 是 热 备 节点 ) 上 执行 这 
个 操作 。 

















译注 1: 2.0 系 统 在 这 方面 有 改进 。 
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。 需要 使 用 是 原来 数据 库 两 倍 的 磁盘 空间 。( 比 方 说 ， 若 有 200 GB 的 数据 ， 则 还 要 


至 少 200 GB 的 空闲 磁盘 空间 才能 运行 repair。) 


很 多 人 都 会 遇 到 的 一 个 问题 就 是 要 通过 repair 处 理 的 数据 量 太 大 ， 比 如 数据 库 可 
能 有 500 GB ， 整 个 服务 器 的 硬盘 也 就 700 GB。 这 种 情况 下 ， 就 只 能 用 mongodump 
和 mongorestore 来 进行 “手工 ”恢复 了 。 


例如 ， 假 设 nyl 主机 上 大 部 分 磁盘 空间 都 被 占用 了 。 数 据 库 有 300 GB ， 而 其 所 在 服 
务 器 上 总 的 磁盘 空间 也 就 400 GB。 但 是 我 们 还 有 ny2， 它 也 有 同样 的 400 GB 硬盘 ， 
但 什么 数据 也 没有 。 首 先 ， 如 果 ny] 是 主 节 点 ， 则 需要 令 其 降级 ， 然 后 执行 fsync 
并 加 锁 ， 这 样 能 确保 磁盘 上 其 数据 的 一 致 性 。 


ua 











> rs.stepDown () 
> db.runCommand({fsynce : 1, lock : 1}) 


然后 登录 到 ny2 上 并 执行 : 
ny2$ mongodump --host ny1 
这 就 会 将 数据 导出 到 ny2 上 的 dump 目录 下 。 
上 面 mongodump 的 执行 速度 很 可 能 会 受到 网 络 速度 的 限制 。 如 果 可 以 在 物理 上 访 
问 机 器 的 话 ， 加 一 块 硬盘 ， 做 本 地 的 mongodump。 
导出 成 功 后 就 可 以 在 nyl 上 恢复 数据 了 ， 如 下 。 


1. 停止 nyl 上 的 mongod 进程 。 

2. 备份 wy7 上 的 数据 文件 (比如 做 EBS 快照 ) ， 以 防 万 一 。 

3. 删除 ny7 上 的 数据 文件 。 

4. 重启 zy7 (现在 没有 数据 )。 如 果 其 在 某 个 复制 组 中 ， 启 动 时 要 指定 一 个 不 同 的 端 
口 并 且 去 掉 -- replset 参数 ， 为 的 是 不 (与 其 他 复制 组 中 的 节点 ) 混 请 。 











最 后 ， 在 ny2 上 执行 mongorestore: 


ny2$ mongorestore --host nyl --port 10000 # specify port if it's not 27017 


这 样 wy7 就 有 压缩 形式 的 数据 库 文件 了 ， 之 后 就 可 以 正常 启动 了 。 


5.3 技巧 41: 不 要 改变 复制 组 成 员 投 票 的 权 值 


要 是 希望 某 个 机 器 优先 成 为 活跃 方 点 ， 需 要 设置 权 值 。1.9.0 中 可 以 为 某 个 市 点 设置 
ARIA, ORC EAA ERAT A. (HAE TE 1.9.0 以 前 的 版 本 中 ， 
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这 个 权 值 只 能 为 1《〈 可 以 成 为 活跃 节点 ) 或 者 0 〈 不 能 成 为 活跃 节点 )。 在 1.9.0 之 
前 的 版 本 中 ， 唯 一 能 让 某 个 节点 总 成 为 活跃 节点 的 方法 就 是 将 基 他 节点 的 权 值 都 设 
为 0。 


人 们 总 是 将 服务 器 依据 权 值 成 为 活跃 市 点 这 一 件 事 与 社会 中 的 投票 选举 等 同 起 来 ， 
认为 可 以 通过 增加 某 个 市 点 的 权 值 来 让 其 赢得 选举 。 但 是 ， 服 务 器 一 点 也 不 “ 自 
私 ”"， 未 必 会 投 自己 的 票 。 复制 组 中 的 市 点 都 是 “公正 无 私 ” 的 ， 对 自己 和 友 邻 都 是 
完全 同等 对 待 的 。 


5.4 技巧 42: 无 活跃 节点 时 可 重 置 复制 组 


如 果 复 制 组 中 只 有 少数 节点 在 运行 ， 系 统 就 会 包 略 本 地 数据 库 ， 然 后 重新 配置 复制 
组 。 对 于 大 多 数 情形 而 言 ， 这 样 做 没什么 问题 ， 但 是 这 样 会 有 一 些 停机 时 间 ， 因 为 
要 重建 复制 组 和 重新 分 配 oplog。 如 果 想 让 应 用 保持 运行 《但 因为 没有 活跃 节点 ， 
所 以 它 只 能 是 只 读 的 ) ， 可 以 ， 但 前 提 是 得 有 多 于 一 个 从 属 节 点 仍 在 工作 。 














选 一 个 从 属 节点 ， 将 其 关 停 ， 然 后 去 掉 --replset 选项 并 用 另外 一 个 端口 启动 。 
例如 ， 若 原本 是 这 样 启动 的 : 


$ mongod --replSet foo --port 5555 


可 以 这 样 重启 : 





$ mongod --port 5556 


这 样 复制 组 中 的 其 他 节点 就 不 会 将 其 作为 这 一 复制 组 的 一 员 
它 本 身 也 将 不 会 使 用 复制 组 的 配置 (因为 根本 就 没 告诉 它 说 
此 刻 ， 它 就 仅仅 是 个 普通 的 mongod 服务 器 。 








了 (因为 端口 不 同 了 )， 
它 曾 是 复制 组 的 一 员 )。 





接 下 来 要 更 改 复制 组 的 配置 信息 ， 因 此 要 通过 shell 连接 这 个 服务 器 。 切 换 到 本 地 
(local) 数据 库 ， 将 复制 组 的 配置 信息 存 到 一 个 JavaScript 变量 中 。 例 如 ， 假 设 复 制 
组 中 有 4 个 节点 ， 看 上 去 可 能 如 下 : 


> use local 
> config = db.system.replset.findoOne () 
{ 

w idt q ROOM, 

"version" : 2, 

"members" : [ 


"ida" : 0, 
"host" : "rs1:5555" 





管理 技巧 | 113 


"4a": 1, 


"host : "rs225555", 

"arbiterOnly" : true 
}, 

"Ga 42; 

"host" + *"rsa:5555" 

t iar è 3y 

"host" + "rs4:5555" 


} 
要 更 改 配置 就 要 将 config 对 象 改 成 我 们 期 望 的 配置 并 且 将 其 标记 为 “最 新 的 "， 这 
样 集群 就 能 自动 更 新 。 


上 面 的 配置 是 针对 4 个 节点 的 集群 的 ， 但 现在 假设 要 将 其 改 成 只 有 3 个 节点 ， 包 括 
rsl, rs2 和 rs4。 为 此 要 把 rs3 从 数组 中 删除 ， 用 JavaScript 的 slice 函数 就 能 完成 : 





> config.slice(2, 1) 
> config{ 


" id" : "foo", 

"version" : 2, 

"members" : [ 
w id" 2 0, 
"host" » "rs1:5555" 
void os hs 
"host" + “rs2:5555", 
"arbiterOnly" : true 
w > ae eC 
"host" : "rs4:5555" 


} 


一 定 不 要 把 rs4 的 ia 改 为 2。 这 样 会 造成 混乱 。 如 果 想 向 集群 中 添加 节点 ， 建 议 
用 JavaScript 的 push 函数 添加 _ id 为 4 5 之 类 的 条 目 。 要 是 想 既 添加 又 删除 节 
点 ， 可 能 有 点 乱 ， 用 JavaScript 函数 splice 就 好 了 (也 可 以 用 push 和 slice). 


然后 增加 版 本 号 (config.version)， 以 此 来 通知 其 他 节点 配置 有 更 新 , 需要 同步 。 
现在 要 再 次 确认 配置 文档 。 若 把 这 配置 搞 坏 了 ， 可 能 会 把 整个 复制 集 的 配置 彻底 搞 











fe 
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坏 。 说 的 明白 点 ， 数 据 没什么 危险 ,但 可 能 得 将 所 有 服务 器 都 关 掉 ， 并 删除 每 个 服 
务 器 上 的 本 地 数据 库 。 所 以 要 确保 这 个 配置 指向 了 正确 的 服务 器 ， 所 有 的 ia 都 没 
有 变 ， 也 没有 把 仲裁 者 和 普通 的 市 点 搞 混 。 


当 确 信和 配置 完全 符合 预期 时 ， 就 可 以 停 掉 服务 器 了 。 然 后 用 正常 参数 重新 启动 就 好 
了 (-replSet 和 标准 的 端口 )。 儿 秒 钟 后 ， 其 他 节点 就 会 对 其 发 起 连接 ， 更 新 自己 的 
配置 ， 然 后 选 出 新 的 活跃 节点 。 


延伸 阅读 : 


。 slice RA (参见 http:/www.w3schools.com/jsref/jsref-slice-array.asp) ; 

。 push 国 数 (参见 http://www.w3schools.com/jsref/jsref-push.asp ) ; 

。 复制 组 选项 (参见 http://www.mongodb.org/display/DOCS/Replicat+Set+Confi guration 
#ReplicaSetCOnfiquxation-TheReplicaSetConfigObject), 


5.5 技巧 43: 不 必 指 定 --shardsvr 和 
- -configsvr 参 数 


依据 文档 来 看 ， 似 乎 配置 分 片 必须 设置 这 些 参数 ， 但 事实 并 非 如 此 。 这 些 参数 大 体 
上 只 是 改变 端口 而 已 (这 个 端口 会 严重 扰乱 已 有 的 复制 组 )，- -shardsvr 将 端口 改 
为 27018，--configsvr 将 端口 改 为 27019。 如 果 在 多 台 机 器 上 设置 多 个 服务 器 ， 
这 样 能 降低 互联 的 难度 ， 使 所 有 mongo 进程 都 运行 在 27017 上 ， 使 所 有 分 片 都 运行 
在 27018 上 ， 使 所 有 配置 服务 器 都 用 27019。 从 零 开 始 创 建 集群 时 ， 这 样 设置 可 以 
极 大 地 帮助 了 解 各 种 情况 ， 但 将 已 有 的 复制 组 切换 到 分 片 也 没 必 要 大 过 担心 。 


--configsvr 不 仅 更 改 默 认 端 口 ， 还 会 开启 diaglog， 它 用 来 以 可 重 放 的 形式 记录 
配置 数据 库 的 所 有 操作 ， 以 防 不 测 。 如 果 用 的 版 本 是 1.6， 则 应 用 - -port 27019 和 
--diaglog 两 个 参数 来 达到 同样 的 目的 ， 因 为 只 有 1.6.5 以 上 版 本 的 --configsvr 
选项 才 会 开启 diaglog。 要 是 使 用 版 本 1.8， 要 用 --port 27019 和 --journal 
(而 不 是 --diaglog)。 日 志和 diaglog 效果 差不多 ， 但 性 能 好 很 多 。 


5.6 #1544: 开发 时 才 用 --notablescan 


MongoDB 有 个 --notablescan 选项 ， 一 旦 开启 ， 就 会 在 某 个 查询 要 做 表 扫 描 时 返 
回 错误 〈 处 理 使 用 索引 的 查询 时 一 切 正常 )。 开 发 时 想 确 保 所 有 查询 都 用 到 索引 时 ， 
这 个 选项 就 非常 有 用 了 ， 但 不 建议 在 生产 环境 中 使 用 。 问 题 是 很 多 简单 的 管理 任务 
都 需要 表 扫 描 。 如 果 已 经 带 着 - -notablescan 参数 开启 了 MongoDB ， 还 想 看 看 数 
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有 索引 的 字段 ? 这 可 不 行 ， 不 允许 表 扫 描 。 


--notablescan 是 调试 的 好 工具 ,但 只 用 索引 查询 通常 极为 不 切实 际 。 





5.7 技巧 45: = JavaScript 


即便 你 用 的 语言 有 很 好 的 shell (比如 Python)， 或 者 有 很 好 的 抽象 层 把 应 用 和 
MongoDB 隔离 开 (比如 Mongoid)， 也 应 该 熟悉 JavaScript shell。 这 种 信息 存 取 方 
式 最 快捷 ， 且 Java Script 是 所 有 MongoDB 开发 者 通用 的 语言 。 


要 尽 可 能 充分 地 利用 shell， 了 解 一 些 Java Script 知识 是 很 有 帮助 的 。 下 面 的 这 些 技 
巧 涉及 这 种 语言 非常 有 用 的 一 些 特性 ， 但 还 远 不 能 满足 你 的 使 用 需求 。 因 特 网 上 有 很 
多 免费 资源 ， 如 果 偏 爱 读 书 (一 定 是 吧 ， 因 为 你 正 读 着 呢 )， 可 以 看 看 《JavaScript 语 
言 精粹 》 FALL (JavaScript 权威 指南 》 而 言 ， 前 者 很 沙 ， 更 易 理 解 (后 者 也 很 棒 ， 但 
是 要 多 出 700 页 )。 这 里 不 能 全 面 介绍 JavaScript 的 有 用 特性 ， 但 这 门 语言 真 的 非常 
灵活 且 功 能 强大 。 


5.8 421546: 在 shell 中 管理 所 有 服务 器 和 数据 库 


默认 情况 下 ，mongo 会 连接 localhost:27017。 启 动 时 可 以 任意 指定 要 连接 的 服务 器 ， 
方法 是 运行 mongo 主机 :端口 / 数据库。 在 shell 下 还 可 以 连接 多 个 服务 器 或 者 数 
据 库 。 


例如 ， 假 设 应 用 需要 两 个 数据 库 : 一 个 customers 数据 库 ， 一 个 game 数据 库 。 同 
时 使 用 两 者 且 需 要 在 两 者 之 间 切 换 时 可 以 用 use customers, use game, use 
customers 等 。 也 可 以 用 不 同 的 变量 表示 不 同 的 数据 库 : 


> db 

test 

> customers = db.getSisterDB ("customers") 
customers 

> game = db.getSisterDB ("game") 

game 





























这 些 变量 和 db 的 用 法 一 样 ， 如 game.players.find(). customers.europe. 
update() 等 。 


也 可 以 将 ab 或 者 别 的 变量 指向 其 他 服务 器 : 


> db = connect ("nyla:27017/f00") 
connecting to: nyla:27017/foo 
foo 
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> db 
foo 


FEIA MARAD SEIN i BEETS PAT, PEER WAR TT. TE shell 
中 可 以 同时 维护 到 主 节 点 和 从 属 节 点 的 连接 : 


> master = connect ("nyla:27017/admin") 
connecting to: nyla:27017/admin 

admin 

> slave = connect ("ny1b:27017/admin") 
connecting to: nylb:27017/admin 

admin 


你 还 能 直接 连接 分 片 服务 器 、 配 置 服务 器 ， 只 要 是 运行 的 MongoDB 服务 器 就 可 以 。 








一 些 shell 函数 ， 尤 其 是 rs 辅助 函数 ， 是 以 ap 作为 当前 数据 库 的 ， 如 果 
ED amp 连接 的 是 从 属 节点 或 者 仲裁 机 ， 有 些 辅助 函数 就 失效 了 。 











利用 shell 连接 多 个 服务 器 有 个 令 人 讨厌 的 地 方 ， 即 MongoDB 会 跟踪 发 起 的 所 有 连 
接 ， 一 旦 连接 丢失 ， 就 不 停 地 报警 ， 直 到 连接 恢复 或 者 重启 shell。 即 便 是 清除 连接 
也 无 效 ! 这 个 错误 会 在 版 本 1.9 中 得 以 修正 ， 不 过 现在 虽然 有 点 恼人 却 也 无 关 紧 要 。 


5.9 技巧 47: 获得 帮助 


Java Script 使 得 我 们 可 以 在 shell 中 看 到 绝 大 部 分 函数 的 源 代 码 。 要 想 知道 函数 接受 
什么 参数 或 者 记 不 住 返 回 值 ， 你 就 可 以 通过 执行 函数 名 但 不 加 括号 来 查看 源 代码 。 
例如 ,假设 我 们 记得 ab .addUser 用 来 添加 一 个 用 户 ， 但 拿 不 准 参 数 是 什么 了 : 























> db.addUser 
function (username, pass, readOnly) { 


readOnly = readOnly || false; 

var c = this.getCollection("system.users") ; 

var u = c.findOne({user: username}) || {user: username}; 
u.readOnly = readOnly; 

u.pwd = hex md5(username + (":mongo:" + pass)); 


print (tojson(u) ) ; 
c.save (u); 
} 
我 们 立刻 就 能 知道 ， 应 该 传 一 个 username (WHF), pass (密码 ) ， 还 有 个 只 读 
的 参数 read Only (创建 给 定数 据 库 的 只 读 用 户 )。 


另外 ， 大 家 也 可 以 在 线 查看 JavaScript API (http: Wapi.mongodb.org/js)。 在 线 文档 
ppm 但 还 算 比 较 完整 的 函数 参考 。 
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还 有 很 多 内 置 的 命令 帮助 。 要 是 想 不 起 来 要 执行 的 命令 也 没关系 ， 只 需 记 住 一 个 命 
A 





& listCommands。 它 会 将 所 有 命令 的 名 称 都 列 出 来 。 
> db.runCommand({listCommands : 1}) 
{ 
"commands" : { 
Ne issalft s “baw PG 
} 
Mok" : 1 


如 果 知 道 命令 名 ， 就 可 以 通过 {commandName : 1, help : 1} (即便 1 对 于 这 个 
命令 本 身 没 有 意义 也 没关系 ) 来 查看 内 置 文档 。 这 种 方式 可 以 显示 各 个 命令 在 数据 
据 库 中 的 基本 文档 ， 有 些 很 有 用 ， 有 的 写 得 不 怎么 样 。 


> db.runCommand({collstats : 1, help : 1}) 


{ 





"help" : "help for: collStats { collStats: "blog.posts" , scale : 1 } 
scale divides sizes e.g. for KB use 1024", 

"lockType" = =1, 

"ok" : 1 


} 
shell 还 有 tab 补 全 功能 ， 因 此 你 可 以 获得 国 数 名 、 字 段 ， 甚 至 是 现 有 集合 名 的 输入 
提示 信息 : 





> ob.e 

db.cloneCollection ( db.constructor db. currentoOP ( 
db.cloneDatabase ( db. copyDatabase ( db.currentOp ( 
db. commandHelp ( db.createCollection ( 


> db.copyDatabase() 


编写 本 书 时 ， 只 有 *NIX 系统 上 实现 了 shell 补 全 。 


5.10 #1548: 创建 启动 文件 

shell 启动 时 可 以 运行 启动 文件 。 启 动 文件 通常 含有 一 组 用 户 自 定义 的 辅助 函数 ， 但 
也 无 非 就 是 个 普通 的 JavaScript 程序 。 要 构建 启动 文件 ， 建 一 个 以 .js 为 后 绥 的 文件 
(比方 说 startup.js) 就 可 以 了 ， 然 后 用 mongo startup.js 启动 。 


比如 ， 假 如 要 做 些 shell 维护 工作 ， 要 避免 意外 删除 数据 库 或 者 记录 。 你 就 可 以 在 
shell 中 删除 一 些 不 太 安 全 的 命令 (比如 删除 数据 库 、 集 合 、 文 档 等 ) : 


// no-delete.js 

delete DBCollection.prototype.drop; 
delete DBCollection.prototype.remove; 
delete DB.prototype.dropDatabase; 


这 样 ， 删 除 集合 时 ，monsgo 无 法 识别 这 一 函数 : 
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$ mongo no-delete.js 

MongoDB shell version: 1.8.0 

connecting to: test 

> db.foo.drop() 

Wed Feb 16 14:24:16 TypeError: db.foo.drop is not a function (shell) :1 


但 这 种 招数 “ 防 君 子 不 防 小 人 ”， 对 于 那些 下 定 决心 删除 集合 的 人 一 点 儿 作 用 都 没 
有 。 所 以 删除 函数 并 不 能 作为 防范 恶意 攻击 的 手段 《本 身 也 不 提供 这 一 作用 )， 它 仅 
仅 用 于 避免 些 误 操 作 而 已 。 


wa 
p 要 是 有 人 真 的 铁 了 心 想 删除 集合 ， 但 找 不 到 drop), REM db. Soma. 
人 4。 findone( {drop : "foo")}) 就 可 以 了 。 要 是 连 这 个 都 不 让 做 就 只 能 把 











WS findo 也 删 掉 ， 但 shell 也 就 没什么 用 处 了 。 


你 可 以 建立 一 个 详尽 的 函数 黑 名 单 ， 这 需要 考虑 实际 情况 (是 要 禁止 创建 索引 ， 还 
是 禁止 执行 数据 库 命令 等 )。mongo 启动 时 可 以 指定 多 个 启动 文件 ， 所 以 可 以 实现 模 
块 化 操作 。 


5.11 技巧 49: BEM me 
如 果 你 想 创建 自 定义 函数 ， 可 以 把 它们 定义 为 全 局 函数 ， 或 者 添加 到 类 的 实例 ， 或 
类 本 身 中 (这 样 类 的 每 个 实例 都 会 包含 这 个 函数 的 一 个 实例 )。 
例如 ， 假 设 像 技巧 46 那样 连接 复制 组 中 的 所 有 节点 ， 需 要 添加 一 个 getoplogLength 
RI BL 
EZE, RN ea MEE (DB) F: 
DB.prototype.getOplogLength = function() { 


var local = this.getSisterDB("local") ; 
var first = local.oplog.rs.find().sort({Snatural : 1}).limit(1).next(); 








var last = local.oplog.rs.find().sort({$natural : -1}).limit (1) .next(); 
print ("total time: " + (last.ts.t - first.ts.t) + " secs"); 


后 ， 连 接 rsA, rsB 和 rsC 这 些 数据 库 时 就 都 会 有 getOplogLength 国 数 。 


要 是 事先 已 经 在 使 用 rsA, rsB 和 5C， 则 即使 你 添加 了 新 函数 到 (它们 用 来 进 实 例 化 的 ) 
类 中 它们 也 不 能 用 。(JavaScript 中 的 类 相当 于 类 实例 的 模板 ， 一 旦 初始 化 完成 ， 实 例 
和 类 就 没有 关系 了 ) 。 如 果 连 接 已 经 初始 化 了 ， 就 得 为 每 个 实例 有 个 添加 这 一 方法 : 


// 将 函数 存 和 人 一 个 变量 以 保存 输入 
var f = function() { ... } 
rsA.getOplogSize 
rsB.getOplogSize 


E; 
ani 
rsC.getOplogSize E 
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你 也 可 以 稍 作 修 改 ， 将 其 作为 全 局 函数 : 


getOplogLength = function(db) { 
var local = db.getSisterDB("local") ; 


oe 
当然 也 可 以 在 对 象 〈 以 及 对 象 的 方法 ) 上 做 类 似 操作 。 


从 文件 加 载 JavaScript 

在 shell 中 可 以 随时 用 loaa O 函数 加 载 JavaScript Æ. load() 加 载 JavaScript X 
件 并 在 shell 上 下 文中 执行 (因此 shell 中 所 有 的 全 局 变量 对 其 可 见 ) 。 你 也 可 以 在 加 
载 的 文件 中 定义 要 在 shell 中 全 局 使 用 的 变量 。 你 也 可 以 在 这 些 文件 中 用 print K 
数 将 输出 呈现 在 shell 中 : 








// hello.js 
print ("Hello, world!") 


然后 在 shell 中 执行 : 


> load("hello.js") 

Hello, world! 
操作 人 员 通 常 想 要 用 配置 文件 设置 复制 组 或 者 分 片 。 这 个 复制 组 和 分 片 的 设置 过 程 
必须 通过 编程 完成 ， 但 你 可 以 把 设置 函数 写 入 JavaScript 文件 ， 然 后 执行 它 就 可 以 
建立 复制 组 。 这 和 使 用 配置 文件 也 差不多 了 。 


5.12 421950: 使 用 单个 连接 读 取 目 身 与 入 
MongoDB 服务 器 的 连接 就 像 一 个 请 求 队列 。 比 方 说 ， 若 通过 这 个 连接 向 数据 库 依 
KRKK A, B, C, W| MongoDB 会 按照 A、B、C 的 发 送 顺序 处 理 。 但 并 不 保 
证 每 个 操作 都 能 成 功 执行 ， 可 能 A 就 关 停 了 服务 器 (为 shutdownServer 命令 )， 
然后 B 和 C 都 会 返回 错误 (要求 返回 执行 结果 的 情况 下 )。 但 是 ， 其 发 送 和 执行 的 
顺序 是 绝对 能 得 到 保证 的 〈 见 图 5-1)。 
































5-1: 到 MongoDB 的 单个 连接 类 似 队列 
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很 有 用 的 。 例 如 假设 增加 了 某 个 产品 的 下 载 次 数 ， 然 后 用 findone 查询 ， 你 会 
得 到 增加 后 的 下 载 次 数 。 但 是 ， 要 是 用 的 是 多 个 连接 (多 数 驱 动 都 会 自动 使 用 
连接 凶 )， 可 能 就 会 事与愿违 。 


假设 有 两 个 到 数据 库 的 连接 (同一 个 客户 端 发 起 的 ) 。 每 个 连接 的 请 求 都 能 按 顺序 
处 理 ， 但 两 个 连接 之 间 就 没有 什么 确定 的 先后 顺序 了 。 如 果 第 一 个 连接 发 送 了 A、 
B、C 这 3 个 请 求 ， 第 二 个 连接 发 送 了 D、E、F 这 3 个 请 求 ， 最 后 处 理 顺 序 可 能 是 
A, D, B, E, C, F, 也 可 能 是 A、B、C、D、E、F， 也 可 能 是 两 个 序列 的 其 他 组 
合 ( 见 图 5-2) 


如 果 A 请 求 是 插入 新 文档 ，D 请 求 是 查询 这 个 文档 ，D 最 后 可 能 跑 在 前 面 了 (比如 
D、A、E、B、F、C 这 样 的 顺序 )， 这 样 就 找 不 到 记录 了 。 为 了 修正 这 一 点 ， 有 连 
接 池 的 驱动 一 般 都 会 提供 一 个 方法 ， 让 一 组 请 求 通过 同一 个 连接 发 送 ， 来 避免 这 种 
“ 读 取 自 己 的 写 入 ”的 了 矛盾。 其 他 的 驱动 会 自动 这 样 处 理 (通常 每 个 “会 话 ”使 用 同 
一 个 连接 ) ， 详 见 驱动 文档 。 


这 是 
希望 












































图 5-2: 请 求 在 同一 个 连接 内 能 保证 处 理 顺序 ， 但 是 在 不 同 的 连接 中 就 无 法 保证 了 
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a 











具体 的 主题 有 : 
”通过 分 片 设置 MongoDB 集 群 ， 
= ”在 集群 中 查询 和 更 新 数据 ， 


”操作 、 监 控 和 备份 集群 ， 
”从 程序 设计 角度 ， 考 虑 如 何 应 对 分 片 、 配 置 服务 器 或 者 mongos 进 程 停止 运行 的 情况 。 





对 于 用 户 而 言 ，MongoDB 上 手 很 容易 ， 但 是 构建 使 用 MongoDB 的 应 用 程序 时 ， 一 些 球 手 的 问题 便 会 接 旺 而 
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发 技巧 50 例 ”呈现 了 一 系列 的 MongoDB 提 示 和 技巧 ， 可 帮助 用 户 解决 与 应 用 程序 设计 与 实现 、 数 据 安 全 和 监 
控 有 关 的 各 种 问题 。 
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Preface 


This text is for MongoDB users who are interested in sharding. It is a comprehensive 
look at how to set up and use a cluster. 


This is not an introduction to MongoDB; I assume that you understand what a docu- 
ment, collection, and database are, how to read and write data, what an index is, and 
how and why to set up a replica set. 


If you are not familiar with MongoDB, it’s easy to learn. There are a number of books 
on MongoDB, including MongoDB: The Definitive Guide from this author. You can 
also check out the online documentation. 


Conventions Used in This Book 


The following typographical conventions are used in this book: 


Italic 
Indicates new terms, URLs, email addresses, filenames, and file extensions. 
Constant width 
Used for program listings, as well as within paragraphs to refer to program elements 
such as variable or function names, databases, data types, environment variables, 
statements, and keywords. 
Constant width bold 
Shows commands or other text that should be typed literally by the user. 
Constant width italic 
Shows text that should be replaced with user-supplied values or by values deter- 
mined by context. 


Va 
4 
This icon signifies a tip, suggestion, or general note. 











vii 


This icon indicates a warning or caution. 


= 





Using Code Examples 


This book is here to help you get your job done. In general, you may use the code in 
this book in your programs and documentation. You do not need to contact us for 
permission unless you’re reproducing a significant portion of the code. For example, 
writing a program that uses several chunks of code from this book does not require 
permission. Selling or distributing a CD-ROM of examples from O’Reilly books does 
require permission. Answering a question by citing this book and quoting example 
code does not require permission. Incorporating a significant amount of example code 
from this book into your product’s documentation does require permission. 


We appreciate, but do not require, attribution. An attribution usually includes the title, 
author, publisher, and ISBN. For example: “Scaling MongoDB by Kristina Chodorow 
(O’Reilly). Copyright 2011 Kristina Chodorow, 978-1-449-30321-1.” 


If you feel your use of code examples falls outside fair use or the permission given above, 
feel free to contact us at permissions@oreilly.com. 


Safari® Books Online 
Saf Safari Books Online is an on-demand digital library that lets you easily 
atarl. search over 7,500 technology and creative reference books and videos to 


find the answers you need quickly. 


With a subscription, you can read any page and watch any video from our library online. 
Read books on your cell phone and mobile devices. Access new titles before they are 
available for print, and get exclusive access to manuscripts in development and post 
feedback for the authors. Copy and paste code samples, organize your favorites, down- 
load chapters, bookmark key sections, create notes, print out pages, and benefit from 
tons of other time-saving features. 


O’Reilly Media has uploaded this book to the Safari Books Online service. To have full 
digital access to this book and others on similar topics from O’Reilly and other pub- 
lishers, sign up for free at http://my.safaribooksonline.com. 


How to Contact Us 
Please address comments and questions concerning this book to the publisher: 


O’Reilly Media, Inc. 
1005 Gravenstein Highway North 
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Sebastopol, CA 95472 

800-998-9938 (in the United States or Canada) 
707-829-0515 (international or local) 
707-829-0104 (fax) 


We have a web page for this book, where we list errata, examples, and any additional 
information. You can access this page at: 


http://oreilly.com/catalog/97 81449303211 
To comment or ask technical questions about this book, send email to: 
bookquestions@oreilly.com 


For more information about our books, courses, conferences, and news, see our website 
at http://www.oreilly.com. 


Find us on Facebook: http://facebook.com/oreilly 
Follow us on Twitter: http://twitter.com/oreillymedia 


Watch us on YouTube: http://www.youtube.com/oreillymedia 
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CHAPTER 1 
Welcome to Distributed Computing! 





In the Terminator movies, an artificial intelligence called Skynet wages war on humans, 
chugging along for decades creating robots and killing off humanity. This is the dream 
of most ops people—not to destroy humanity, but to build a distributed system that 
will work long-term without relying on people carrying pagers. Skynet is still a pipe 
dream, unfortunately, because distributed systems are very difficult, both to design well 
and to keep running. 


A single database server has a couple of basic states: it’s either up or down. If you add 
another machine and divide your data between the two, you now have some sort of 
dependency between the servers. How does it affect one machine if the other goes 
down? Can your application handle either (or both) machines going down? What if the 
two machines are up, but can’t communicate? What if they can communicate, but only 
very, very, slowly? 


As you add more nodes, these problems just become more numerous and complex: 
what happens if entire parts of your cluster can’t communicate with other parts? What 
happens if one subset of machines crashes? What happens if you lose an entire data 
center? Suddenly, even taking a backup becomes difficult: how do you take a consistent 
snapshot of many terabytes of data across dozens of machines without freezing out the 
application trying to use the data? 


If you can get away with a single server, it is much simpler. However, if you want to 
store a large volume of data or access it at a rate higher than a single server can handle, 
you'll need to set up a cluster. On the plus side, MongoDB tries to take care of a lot of 
the issues listed above. Keep in mind that this isn’t as simple as setting up a single 
mongod (then again, what is?). This book shows you how to set up a robust cluster and 
what to expect every step of the way. 





What Is Sharding? 


Sharding is the method MongoDB uses to split a large collection across several servers 
(called a cluster). While sharding has roots in relational database partitioning, it is (like 
most aspects of MongoDB) very different. 


The biggest difference between any partitioning schemes you’ve probably used and 
MongoDB is that MongoDB does almost everything automatically. Once you tell Mon- 
goDB to distribute data, it will take care of keeping your data balanced between servers. 
You have to tell MongoDB to add new servers to the cluster, but once you do, MongoDB 
takes care of making sure that they get an even amount of the data, too. 


Sharding is designed to fulfill three simple goals: 


Make the cluster “invisible.” 
We want an application to have no idea that what it’s talking to is anything other 
than a single, vanilla mongod. 


To accomplish this, MongoDB comes with a special routing process called mon- 
gos. mongos sits in front of your cluster and looks like an ordinary mongod server 
to anything that connects to it. It forwards requests to the correct server or servers 
in the cluster, then assembles their responses and sends them back to the client. 
This makes it so that, in general, a client does not need to know that they’re talking 
to a cluster rather than a single server. 


There are a couple of exceptions to this abstraction when the nature of a cluster 
forces it. These are covered in Chapter 4. 


Make the cluster always available for reads and writes. 
A cluster can’t guarantee it’ll always be available (what if the power goes out ev- 
erywhere?), but within reasonable parameters, there should never be a time when 
users can’t read or write data. The cluster should allow as many nodes as possible 
to fail before its functionality noticeably degrades. 


MongoDB ensures maximum uptime in a couple different ways. Every part of a 
cluster can and should have at least some redundant processes running on other 
machines (optimally in other data centers) so that if one process/machine/data 
center goes down, the other ones can immediately (and automatically) pick up the 
slack and keep going. 


There is also the question of what to do when data is being migrated from one 
machine to another, which is actually a very interesting and difficult problem: how 
do you provide continuous and consistent access to data while it’s in transit? We’ve 
come up with some clever solutions to this, but it’s a bit beyond the scope of this 
book. However, under the covers, MongoDB is doing some pretty nifty tricks. 


Let the cluster grow easily 
As your system needs more space or resources, you should be able to add them. 
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MongoDB allows you to add as much capacity as you need as you need it. Adding 
(and removing) capacity is covered further in Chapter 3. 


These goals have some consequences: a cluster should be easy to use (as easy to use as 
a single node) and easy to administrate (otherwise adding a new shard would not be 
easy). MongoDB lets your application grow—easily, robustly, and naturally—as far as 
it needs to. 





What Is Sharding? | 3 


CHAPTER 2 
Understanding Sharding 





To set up, administrate, or debug a cluster, you have to understand the basic scheme 
of how sharding works. This chapter covers the basics so that you can reason about 
what’s going on. 


Splitting Up Data 


A shard is one or more servers in a cluster that are responsible for some subset of the 
data. For instance, if we had a cluster that contained 1,000,000 documents representing 
a website’s users, one shard might contain information about 200,000 of the users. 


A shard can consist of many servers. If there is more than one server in a shard, each 
server has an identical copy of the subset of data (Figure 2-1). In production, a shard 
will usually be a replica set. 

















Figure 2-1. A shard contains some subset of the data. If a shard contains more than one server, each 
server has a complete copy of the data. 


To evenly distribute data across shards, MongoDB moves subsets of the data from shard 
to shard. It figures out which subsets to move based on a key that you choose. For 
example, we might choose to split up a collection of users based on the username field. 
MongoDB uses range-based splitting; that is, data is split into chunks of given ranges 
—e.g., ["a”, “f”). 





Throughout this text, Ill use standard range notation to describe ranges. “[” and “]” 
denote inclusive bounds and “(” and “)” denote exclusive bounds. Thus, the four pos- 
sible ranges are: 


x is in (a, b) 

If there exists an x such that a < x < b 
x is in (a, b] 

If there exists an x such that a < x <b 
x is in [a, b) 

If there exists an x such that a < x <b 
x is in [a, b] 

If there exists an x such that a < x < b 


MongoDB’s sharding uses [a, b) for almost all of its ranges, so that’s mostly what you'll 

see. This range can be expressed as “from and including a, up to but not including b.” 

For example, say we have a range of username ["a”, “f”). Then “a”, “charlie”, and “ez- 
oe 


bake” could be in the set, because, using string comparison, “a” < “a” < “charlie” < 
“ez-bake” < Gh: 


The range includes everything up to but not including “f”. Thus, “ez-bake” could be in 
the set, but “f” could not. 


Distributing Data 


MongoDB uses a somewhat non-intuitive method of partitioning data. To understand 
why it does this, we’ll start by using the naive method and figure out a better way from 
the problems we run into. 


One range per shard 


The simplest way to distribute data across shards is for each shard to be responsible 
for a single range of data. So, if we had four shards, we might have a setup like Fig- 
ure 2-2. In this example, we will assume that all usernames start with a letter between 


“a” and “z”, which can be represented as ["a”, “{”). “{” is the character after “z” in 
ASCII. 





ra f “f ”) AK : “n”) ["n” i w ["t” : TY 


Shard 1 Shard 2 Shard 3 Shard 4 











Figure 2-2. Four shards with ranges ["a”, “f”), I'P, “n”), ["n”, “t”), and ["t”, “{”) 
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This is a nice, easy-to-understand system for sharding, but it becomes inconvenient in 
a large or busy system. It’s easiest to see why by working through what would happen. 


Suppose a lot of users start registering names starting with ["a”, “f”). This will make 
Shard 1 larger, so we’ll take some of its documents and move them to Shard 2. We can 
adjust the ranges so that Shard 1 is (say) ["a”, “c”) and Shard 2 is ["c”, “n”) (see 
Figure 2-3). 





Pe” : “f”) 


ra “16 wen Mo WI hig Hat! tigi 
sin Wi [mw Per, 
Shard 1 Shard 2 Shard 3 Shard 4 


la”, en Ka À “n”) ["n’, aw H 坑 P “gy 
Shard 1 Shard 2 Shard 3 Shard 4 














Figure 2-3. Migrating some of Shard 1’s data to Shard 2. Shard 1’s range is reduced and Shard 2’s is 
expanded. 


Everything seems okay so far, but what if Shard 2 is getting overloaded, too? Suppose 
Shard 1 and Shard 2 have 500GB of data each and Shard 3 and Shard 4 only have 
300GB each. Given this sharding scheme, we end up with a cascade of copies: we’d 
have to move 100GB from shard 1 to Shard 2, then 200GB from shard 2 to shard 3, 
then 100GB from shard 3 to shard 4, for a total of 400GB moved (Figure 2-4). That’s 
a lot of extra data moved considering that all movement has to cascade across the 
cluster. 


How about adding a new shard? Let’s say this cluster keeps working and eventually we 
end up having 500GB per shard and we add a new shard. Now we have to move 400GB 
from Shard 4 to Shard 5, 300GB from Shard 3 to Shard 4, 200GB from Shard 2 to Shard 
3, 100GB from Shard 1 to Shard 2 (Figure 2-5). That’s 1TB of data moved! 
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500 GB 500 GB 300 GB 









400 GB 400 GB 400 GB 400 GB 


Figure 2-4. Using a single range per shard creates a cascade effect: data has to be moved to the server 
“next to” it, even if that does not improve the balance 


500 GB 500 GB 500 GB 500 GB 
Shard 1 Shard 2 Shard 3 Shard 4 
.200 =. 300 GB .400 2. 
400 GB 400 GB 400 GB 400 GB 400 GB 
Shard 1 Shard 2 Shard 3 Shard 4 Shard 5 


Figure 2-5. Adding a new server and balancing the cluster. We could cut down on the amount of data 
transferred by adding the new server to the “middle” (between Shard 2 and Shard 3), but it would 
still require 600GB of data transfer. 














0 GB 
Shard 5 
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This cascade situation just gets worse and worse as the number of shards and amount 
of data grows. Thus, MongoDB does not distribute data this way. Instead, each shard 
contains multiple ranges. 


Multi-range shards 


Let’s consider the situation pictured in Figure 2-4 again, where Shard 1 and Shard 2 
have 500GB and Shard 3 and Shard 4 have 300GB. This time, we’ll allow each shard 
to contain multiple chunk ranges. 


This allows us to divide Shard 1’s data into two ranges: one of 400GB (say ["a”, “d”)) 
and one of 100GB (["d”, “f”)). Then, we’ll do the same on Shard 2, ending up with 
["f?, j”) and ["j”, “n”). Now, we can migrate 100GB (["d”, “f”)) from Shard 1 to Shard 
3 and all of the WE in the ["j”, “n”) range from Shard 2 to Shard 4 (see Fig- 
ure 2-6). A range of data is called a chunk. When we split a chunk’s range into two 
ranges, it becomes two chunks. 


500 GB 500 GB 300 GB 300 GB 
Shard 1 Shard 2 Shard 3 Shard 4 





400 GB 400 GB 400 GB 400 GB 
Shard 1 Shard 2 Shard 3 Shard 4 


Figure 2-6. Allowing multiple, non-consecutive ranges in a shard allows us to pick and choose data 
and to move it anywhere 











Now there are 400GB of data on each shard and only 200GB of data had to be moved. 


If we add a new shard, MongoDB can skim 100GB off of the top of each shard and 
move these chunks to the new shard, allowing the new shard to get 400GB of data by 
moving the bare minimum: only 400GB of data (Figure 2-7). 
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500 GB 500 GB 500 GB 500 GB 0 GB 
Shard 1 Shard 2 Shard 3 Shard 4 Shard 5 


v 


400 GB 400 GB 400 GB 400 GB 
Shard 1 Shard 2 Shard 3 Shard 4 Shard 5 


Figure 2-7. When a new shard is added, everyone can contribute data to it directly 














This is how MongoDB distributes data between shards. As a chunk gets bigger, Mon- 
goDB will automatically split it into two smaller chunks. If the shards become unbal- 
anced, chunks will be migrated to correct the imbalance. 


How Chunks Are Created 


When you decide to distribute data, you have to choose a key to use for chunk ranges 
(we’ve been using username above). This key is called a shard key and can be any field 
or combination of fields. (We’ll go over how to choose the shard key and the actual 
commands to shard a collection in Chapter 3.) 


Example 
Suppose our collection had documents that looked like this (_ids omitted): 
"username" : "paul", "age" : 23} 
"username" : "simon", "age" : 17} 
"username" : "widdly", "age" : 16} 
"username" : "scuds", "age" : 95} 
"username" : "grill", "age" : 18} 
"username" : "flavored", "age" : 55} 
"username" : "bertango", "age" : 73} 
"username" : "wooster", "age" : 33} 


If we choose the age field as a shard key and end up with a chunk range [15, 26), the 
chunk would contain the following documents: 


"username" : "paul", "age" : 23} 

"username" : "simon", "age" : 17} 
"username" : "widdly", "age" : 16} 
"username" : "grill", "age" : 18} 





10 | Chapter 2: Understanding Sharding 


As you can see, all of the documents in this chunk have their age value in the chunk’s 
range. 


Sharding collections 


When you first shard a collection, MongoDB creates a single chunk for whatever data 
is in the collection. This chunk has a range of (-co, œ), where -co is the smallest value 
MongoDB can represent (also called $minKey) and co is the largest (also called $maxKey). 


Na 
sS If you shard a collection containing a lot of data, MongoDB will imme- 
4 ` diately split this initial chunk into smaller chunks. 








The collection in the example above is too small to actually trigger a split, so you’d end 
up with a single chunk—(-%, œ)—until you inserted more data. However, for the 
purposes of demonstration, let’s pretend that this was enough data. 





MongoDB would split the initial chunk (-%, ce) into two chunks around the midpoint 
of the existing data’s range. So, if approximately half of the documents had a an age 
field less than 15 and half were greater than 15, MongoDB might choose 15. Then we’d 
end up with two chunks: (-œ, 15), [15, co) (Figure 2-8). If we continued to insert data 
into the [15, œ) chunk, it could be split again, into, say, [15, 26) and [26, œ). So now 
we have three chunks in this collection: (-œ, 15), [15, 26), and [26, œ). As we insert 
more data, MongoDB will continue to split existing chunks to create new ones. 


You can have a chunk with a single value as its range (e.g., only users with the username 
“paul”), but every chunk’s range must be distinct (you cannot have two chunks with 
the range ["a”, “f”)). You also cannot have overlapping chunks; each chunk’s range 
must exactly meet the next chunk’s range. So, if you split a chunk with the range /4, 
8), you could end up with [4, 6) and [6, 8) because together, they fully cover the original 
chunk’s range. You could not have [4, 5) and [6, 8) because then your collection is 
missing everything in [5, 6). You could not have [4, 6) and [5, 8) because then chunks 
would overlap. Each document must belong to one and only one chunk. 


As MongoDB does not enforce any sort of schema, you might be wondering: where is 
a document placed if it doesn’t have a value for the shard key? MongoDB won’t actually 
allow you to insert documents that are missing the shard key (although using nu11 for 
the value is fine). You also cannot change the value of a shard key (with, for example, 
a $set). The only way to give a document a new shard key is to remove the document, 
change the shard key’s value on the client side, and reinsert it. 


What if you use strings for some documents and numbers for others? It works fine, as 
there is a strict ordering between types in MongoDB. If you insert a string (or an array, 
boolean, null, etc.) in the age field, MongoDB would sort it according to its type. The 
ordering of types is: 
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Figure 2-8. A chunk splitting into two chunks 


null < numbers < strings < objects < arrays < binary data < ObjectIds < booleans 
< dates < regular expressions 


“i” e,» 


Within a type, orderings are as you’d probably expect: 2 < 4, “a” < “z”. 


In the first example given, chunks are hundreds of gigabytes in size, but in a real system, 
chunks are only 200MB by default. This is because moving data is expensive: it takes 
alot of time, uses system resources, and can add a significant amount of network traffic. 
You can try it out by inserting 200MB into a collection. Then try fetching all 200MB 
of data. Then imagine doing this on a system with multiple indexes (as your production 
system will probably have) while other traffic is coming in. You don’t want your ap- 
plication to grind to a halt while MongoDB shuffles data in the background; in fact, if 
a chunk gets too big, MongoDB will refuse to move it at all. You don’t want chunks to 
be too small, either, because each chunk has a little bit of administrative overhead to 
requests (so you don’t want to have to keep track of zillions of them). It turns out that 
200MB is the sweet spot between portability and minimal overhead. 








Va, 
SS A chunk is a logical concept, not a physical reality. The documents in a 
43 chunk are not physically contiguous on disk or grouped in any way. 
~~ aS They may be scattered at random throughout a collection. A document 


belongs in a chunk if and only if its shard key value is in that chunk’s 
range. 
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Balancing 


If there are multiple shards available, MongoDB will start migrating data to other shards 
once you have a sufficient number of chunks. This migration is called balancing and is 
performed by a process called the balancer. 


The balancer moves chunks from one shard to another. The nice thing about the bal- 
ancer is that it’s automatic—you don’t have to worry about keeping your data even 
across shards because it’s done for you. This is also the downside: it’s automatic, so if 
you don’t like the way it’s balancing things, tough luck. If you decide you don’t want 
a certain chunk on Shard 3, you can manually move it to Shard 2, but the balancer will 
probably just pick it up and move it back to Shard 3. Your only options are to either 
re-shard the collection or turn off balancing. 


As of this writing, the balancer’s algorithm isn’t terribly intelligent. It moves chunks 
based on the overall size of the shard and calls it a day. It will become more advanced 
in the (near) future. 


The goal of the balancer is not only to keep the data evenly distributed but also to 
minimize the amount of data transferred. Thus, it takes a lot to trigger the balancer. 
For a balancing round to occur, a shard must have at least nine more chunks than the 
least-populous shard. At that point, chunks will be migrated off of the crowded shard 
until it is even with the rest of the shards. 


The reason the balancer isn’t very aggressive is that MongoDB wants to avoid sending 
the same data back and forth. If the balancer balanced out any tiny difference, it could 
constantly waste resources: Shard 1 would have two chunks more than Shard 2, so it 
would send Shard 2 one chunk. Then a few writes would go to Shard 2, and Shard 2 
would end up with two more chunks than Shard 1 and send the original chunk right 
back (Figure 2-9). By waiting for a more severe imbalance, MongoDB can minimize 
pointless data transfers. Keep in mind that nine chunks is not even that much of an 
imbalance—it is less than 2GB of data. 
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Figure 2-9. If every slight imbalance is corrected, a lot of data will end up moving unnecessarily 


The Psychopathology of Everyday Balancing 


Most users want to prove to themselves that sharding works by watching their data 
move, which creates a problem: the amount of data it takes to trigger a balancing round 
is larger than most people realize. 


Let’s say I’m just playing with sharding, so I write a shell script to insert half a million 
documents into a sharded collection. 


> for (i=0; i<500000; i++) { 
db.foo.insert({"_id" : i, "x" : 1,"y" : 2, "z" : i, "date" : new Date(), 
"foo" : "bar"}); 
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After half a million documents, I should see some data flying around, right? Wrong. If 
I take a look at the database stats, I still have a ways to go (some fields have been omitted 
for clarity): 


> db.stats() 


" " 


raw" : 
"ubuntu:27017" : { 
/* shard stats */ 
h 


"ubuntu:27018" : { 
/* shard stats */ 
} 
}, 


"objects" : 500008, 

"avg0bjSize" : 79.99937600998383, 

"dataSize" : 40000328, 

"storageSize" : 69082624, 

"ok" : 1 

} 

Ifyou look at dataSize, you can see that I have 40,000,328 bytes of data, which is roughly 
equivalent to 40MB. That’s not even a chunk. That’s not even a quarter of a chunk! To 
actually see data move, I would need to insert 2GB, which is 25 million of these docu- 
ments, or 50 times as much data as I am currently inserting. 


When people start sharding, they want to see their data moving around. It’s human 
nature. However, in a production system, you don’t want a lot of migration because 
it’s a very expensive operation. So, on the one hand, we have the very human desire to 
see migrations actually happen. On the other hand, we have the fact that sharding won’t 
work very well if it isn’t irritatingly slow to human eyes. 


What MongoDB did was implement two “tricks” to make sharding more satisfying for 
users, but not destructive to production systems. 


Trick 1: Custom chunk size 
When you start up your first mongos, you can specify --chunkSize N, where Nis the 
chunk size that you want in megabytes. If you’re just trying out sharding and 
messing around, you can set --chunkSize 1 and see your data migrating after a 
couple of megabytes of inserts. 

Trick 2: Ramping up chunk size 
Even if you’re deploying a real application, getting to 2GB can seem to take forever. 
So, for the first dozen or so chunks, MongoDB artificially lowers the chunk size 
automatically, from 200MB to 64MB, just to give people a more satisfying expe- 
rience. Once you have a bunch of chunks, it ramps the chunk size back up to 
200MB automatically. 
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On changing chunk size 


Chunk size can be changed by starting with --chunkSize N or modifying the config.set- 
tings collection and restarting everything. However, unless you’re trying out the 1MB 
chunk size for fun, don’t mess with the chunk size. 


I guarantee that, whatever you’re trying to fix, fiddling with chunk size is not going to 
solve the root problem. It’s a tempting knob to play with, but don’t. Leave chunk size 
alone unless you want to play around with --chunkSize 1. 


mongos 


mongos is the interaction point between users and the cluster. Its job is to hide all of 
the gooey internals of sharding and present a clean, single-server interface to the user 
(you). There are a few cracks in this veneer, which are discussed in Chapter 4, but 
mongos mostly lets you treat a cluster as a single server. 


When you use a cluster, you connect to a mongos and issue all reads and writes to that 
mongos. You should never have to access the shards directly (although you can if you 
want). 


mongos forwards all user requests to the appropriate shards. If a user inserts a docu- 
ment, mongos looks at the document’s shard key, looks at the chunks, and sends the 
document to the shard holding the correct chunk. 


For example, say we insert {"foo" : "bar"} and we’re sharding on foo. mongos looks 
at the chunks available and sees that there is a chunk with the range ["a”, “c”), which 
is the chunk that should contain “bar”. This chunk lives on Shard 2, so mongos sends 
the insert message to Shard 2 (see Figure 2-10). 








{" foo" . "bar"} ices 











Figure 2-10. Routing a request to a shard with the corresponding chunk 
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Ifa query involves the shard key, mongos can use the same process it did to do the insert 
and find the correct shard (or shards) to send the query to. This is called a targeted 
query because it only targets shards that may have the data we’re looking for. If it knows 
we're looking for {"foo" : "bar"}, there’s no sense in querying a shard that only con- 
tains shard key values greater than “bar”. 


If the query does not contain the shard key, mongos must send the query to all of the 
shards. These can be less efficient than targeted queries, but isn’t necessarily. A 
“spewed” query that accesses a few indexed documents in RAM will perform much 
better than a targeted query that has to access data from disk across many shards (a 
targeted query could hit every shard, too). 


The Config Servers 


mongos processes don’t actually store any data persistently, so the configuration of a 
cluster is held on special mongods called config servers. Config servers hold the definitive 
information about the cluster for everyone’s access (shards, mongos processes, and 
system administrators). 


For a chunk migration to succeed, all of the configuration servers have to be up. If one 
of them goes down, all currently occurring migrations will revert themselves and stop 
until you get a full set of config servers up again. If any config servers go down, your 
cluster’s configuration cannot change. 


The Anatomy of a Cluster 


A MongoDB cluster basically consists of three types of processes: the shards for actually 
storing data, the mongos processes for routing requests to the correct data, and the 
config servers, for keeping track of the cluster’s state (Figure 2-11 and Figure 2-12). 





Cluster 


config— 
config servers 














Figure 2-11. Three components of a cluster. 
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Figure 2-12. Each component can contain multiple processes. 


Each of the components above is not “a machine.” mongos processes are usually run 
on appservers. Config servers, for all their importance, are pretty lightweight and can 
basically be run on any machine available. Each shard usually consists of multiple ma- 
chines, as that’s where the data actually lives. 
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CHAPTER 3 
Setting Up a Cluster 





Choosing a Shard Key 


Choosing a good shard key is absolutely critical. If you choose a bad shard key, it can 
break your application immediately or when you have heavy traffic, or it can lurk in 
wait and break your application at a random time. 


On the other hand, if you choose a good shard key, MongoDB will just do the right 
thing as you get more traffic and add more servers, for as long as your application is up. 


As you learned in the last chapter, a shard key determines how your data will be dis- 
tributed across your cluster. Thus, you want a shard key that distributes reads and 
writes, but that also keeps the data you’re using together. These can seem like contra- 
dictory goals, but it can often be accomplished. 


First we’ll go over a couple of bad shard key choices and find out why they’re bad, then 
we'll come up with a couple of better ones. There is also a good page on the MongoDB 
wiki on choosing a shard key. 


Low-Cardinality Shard Key 


Some people don’t really trust or understand how MongoDB automatically distributes 
data, so they think something along the lines of, “I have four shards, so I will use a field 
with four possible values for my shard key.” This is a really, really bad idea. 


Let’s look at what happens. 


Suppose we have an application that stores user information. Each document has a 
continent field, which is where the user is located. Its value can be “Africa”, “Antarc- 
tica”, “Asia”, “Australia”, “Europe”, “North America”, or “South America”. We decide 
to shard on this key because we have a data center on each continent (okay, maybe not 
Antarctica) and we want to server people’s data from their “local” data center. 


The collection starts off with one chunk—(-œ, co) 一 on a shard in some data center. 
All your inserts and reads go to that one chunk. Once that chunk gets big enough, it’ll 
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split into two chunks with ranges (-œ, “Europe”) and ["Europe”, ce). All of the docu- 
ments from Africa, Antarctica, Asia, or Australia go into the first chunk and all of the 
documents from Europe, North America, or South America will go into the second 
chunk. As you add more documents, eventually you’ll end up with seven chunks 
(Figure 3-1): 

e (-œ, “Antarctica”) 

e ["Antarctica”, “Asia”) 

e ["Asia”, “Australia”) 

。 ["Australia”, “Europe”) 

e ["Europe”, “North America”) 

e ["North America”, “South America”) 


。 ["South America”, œ) 





[-%, [“Antartica’, [Asia’ [“Australia’, §j [“Europe’, ["N. America’, ff [“S. America”, 
“Antartica”) Ql “Asia”) “Australia”) § “Europe”) "N. America”) § “S. America”) 目 00) 














Figure 3-1. One shard per continent 


Now what? 


MongoDB can’t split these chunks any further! The chunks will just keep getting bigger 
and bigger. This is fine for a while, but what happens when you start running out of 
space on your servers? There’s nothing you can do, aside from getting a bigger hard disk. 


This choice of shard key is called a low-cardinality shard key, because there are a limited 
number of shard key values. If you choose a shard key with low cardinality, you will 
end up with large, unmovable, unsplittable chunks that will make your life miserable. 


If you are doing this because you want to manually distribute your data, do not use 
MongoDB’s built-in sharding. You'll be fighting it all the way. However, you can cer- 
tainly manually shard your collections, write your own router, and route reads and 
writes to whichever server(s) you’d like. It’s just easier to choose a good shard key and 
let MongoDB do it for you. 


Keys that this rule applies to 


This rule applies to any key that has a finite number of values. Keep in mind that, if a 
key has N values in a collection, you can only have N chunks and, therefore, N shards. 


If you are tempted to use low-cardinality shard key because you query on that field a 
lot, use a compound shard key (a shard key with two fields) and make sure that the 
second field has lots of different values MongoDB can use for splitting. 
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Exceptions to the rule 


If a collection has a lifetime (e.g., you’re creating a new collection each week and you 
know that, ina single week, you won’t get near the capacity of any of your shards), you 
could choose this as a key. 


Data center awareness 


This example is not just about choosing a low-cardinality shard key, but also about 
trying to hack data-center awareness into MongoDB’s sharding. Sharding does not yet 
support data center awareness. If you’re interested in this, you can watch/vote for the 
relevant bug. 


The problem with hacking it together yourself is that it isn’t very extensible. What 
happens if your application is big in Japan? Now you want to add a second shard to 
handle Asia. 


How are you going to migrate data over? You can’t move a chunk once it’s more than 
a few gigabytes in size, and you can’t split the chunk because there is only one shard 
key value in the whole chunk. You can’t just update all of the documents to use a more 
unique value because you can’t update a shard key value. You could remove each 
document, change the shard key’s value, and resave it, but that is not a swift operation 
for a large database. 


The best you can do is start inserting “Asia, Japan” instead of just “Asia”. Then you 
will have old documents that should be “Asia, Japan” but are just “Asia” and then your 
application logic will have to support both. Also, once you start having finer-grained 
chunks, there’s no guarantee MongoDB will put them where you want (unless you turn 
off the balancer and do everything manually). 


Data-center awareness is very important for large applications and it’s a high priority 
for MongoDB developers. Choosing a low-cardinality shard key is not a good solution 
for the interim. 


Ascending Shard Key 


Reading data from RAM is faster than reading data from disk, so the goal is to have as 
much data as possible accessed in RAM. Thus, we want a shard key that keeps data 
together if it will be accessed together. For most applications, recent data is accessed 
more than older data, so people will often try to use something like a timestamp or 
ObjectId field for a shard key. This does not work as well as they expect it to. 


Let’s say we have a Twitter-like service where each document contains a short message, 
who sent it, and when it was sent. We shard on when it was sent, in seconds since the 
epoch. 


We start out with one chunk: (-co, œ), as always. All the inserts go to this shard until 
it splits into something like (-co, 1294516901), [1294516901, œ). Now, we split chunks 
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at their midpoint, so when we split the chunk, the current timestamp is probably well 
after 1294516901. This means that all inserts will be going to the second chunk— 
nothing will be hitting the first anymore. Once the second chunk fills up, it’ll be split 
up into (1294516901, 1294930163), [1294930163, œ). But now the time will be after 
1294930163, so everything will be added to the [1294930163, co) chunk. This pattern 
continues: everything will always be added to the “last” chunk, meaning everything 
will be added to one shard. 


This shard key gives you a single, undistributable hot spot. 


Keys that this rule applies to 


This rule applies to anything ascending; it doesn’t have to be a timestamp. This includes 
ObjectIds, dates, auto-incrementing primary keys (imported from other databases, 
possibly). If the key’s values trend towards infinity, you will have this problem. 


Exceptions to the rule 


Basically, this shard key is always a bad idea because it guarantees you'll have a hotspot. 
If you have low traffic so that a single shard can handle almost all reads and writes, this 
could work. Of course, if you get a traffic spike or become more popular, it would stop 
working and be difficult to fix. 


Don’t use an ascending shard key unless you’re sure you know what you’re doing. 
There are better shard keys—this one should be avoided. 


Random Shard Key 


Sometimes, in an effort to avoid a hotspot, people choose a field with random values 
to shard by. This will work fine at first, but as you get more data, it can become slower 
and slower. 


Let’s say we’re storing thumbnail photos ina sharded collection. Each document con- 
tains the binary data for the photo, an MD5 hash of the binary data, a description, the 
date it was taken, and who took it. We decide to shard on the MD5 hash. 


As our collection grows, we end up with a pretty even number of chunks evenly dis- 
tributed across our shards. So far so good. Now, let’s say we’re pretty busy and a chunk 
on Shard 2 fills up and splits. The configuration server notices that Shard 2 has 10 more 
chunks than Shard 1 and decides it should even things out. MongoDB now has to load 
a random five chunks’ worth of data into memory and send it to Shard 1. This is data 
that wouldn’t have been in memory ordinarily, because it’s a completely random order 
of data. So, now MongoDB is going to be putting a lot more pressure on RAM and 
there’s going to be a lot of disk IO going on (which is always slow). 





22 | Chapter3: Setting Up a Cluster 


You must have an index on the key you shard by, so if you choose a randomly-valued 
key that you don’t query by, you're basically “wasting” an index. Every additional index 
makes writes slower, so it’s important to keep the number of indexes as low as possible. 


Good Shard Keys 


What we really want is something that takes into account our access patterns. If our 
application is regularly accessing 25GB of data, we’d like to have all splits and migrates 
happen in the 25GB of data, not access data in a random pattern that must constantly 
copy new data from disk to memory. 


So, we want to choose a shard key with nice data locality, but not so local that we end 
up with a hot spot. 


Coarsely ascending key + search key 


Many applications access new data more often than older data, so we want data to be 
roughly ordered by date, but also distributed evenly. This keeps the data we’re reading 
and writing in memory, but distributes the load across the cluster. 


We can accomplish this with a compound shard key—something like {coarselyAscend 
ing : 1, search : 1}. The coarselyAscending key should have between a few dozen 
and a few hundred chunks per value and the search key should be something that the 
application commonly queries by. 


For example, let’s say we have an analytics application where our users regularly access 
the last month worth of data; we want to keep that data handy. We’ll shard on {month : 
1, user : 1}. month isa coarsely ascending field, which means that every month it has 
a new, increasing value. user is a good second field because we’ll often be querying for 
a certain user’s data. 


We'll start out with our one chunk, which now has a compound range: ((-co,-co), (co， 
co)). As it fills up, we split the chunk into two chunks, something like ((-%, -co), 
(“2011-04”, “susan”)) and [(“2011-04”, “susan”), (co œ)). Now, assuming it’s still April 
(“2011-04”), the writes will be evenly distributed between the two chunks. All users 
with usernames less than “susan” will be put on the first chunk and all users with 
usernames greater than “susan” will be put on the second chunk. 


As the data continues to grow, this continues to work. Subsequent chunks created in 
April will be moved to different shards, so reads and writes will be balanced across the 
cluster. In May, we start creating chunks with “2011-05” in their bounds. When June 
rolls around, we aren’t accessing the data from “04-2011” chunks anymore, so these 
chunks can quietly drop out of memory and stop taking up resources. We might want 
to look at them again for historical reasons, but they should never need to be split or 
migrated (the problem we ran into with random indexes). 
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FAQ 


Why not just use {ascendingkey : 1} as the shard key? 
This was covered in “Ascending Shard Key” and, if you combine it with a rough- 
grained ascending key, it can also create giant, unsplittable chunks. 


Can search be an ascending field, too? 
No. If itis, the shard key will degenerate into an ascending key and you'll have the 
same hotspot problems a vanilla ascending key gives you. 


So what should search be? 
Hopefully, the search field can be something useful your application can use for 
querying, possibly user info (as in the example above), a filename field, a GUID, 
etc. It should be a fairly randomly distributed non-ascending key with decent car- 
dinality. 


The general case 
We can generalize this to a formula for shard keys: 
{coarseLocality : 1, search : 1} 
coarseLocality is whatever locality you want for your data. search is acommon search 
on your data. 


This key is not the only possible shard key and it won’t work well for everything. 
However, it’s a good way to start thinking about how to choose a shard key, even if 
you do not ultimately use it. 


What shard key should | use? 


Not knowing your application, I can’t really tell you. Choosing a good shard key should 
take some work. Before you choose one, think about the answers to these questions: 


e What do writes look like? What is the shape and size of the documents you’re 
inserting? 

。 How much data is the system writing per hour? Per day? Peak? 

。 What fields are random, and which ones are increasing? 

。 What do reads look like? What data are people accessing? 

。 How much data is the system reading per hour? Per day? Peak? 

。 Is the data indexed? Should it be indexed? 

¢ How much data is there, total? 


There may be other patterns that you find in your data—use them! Before you shard, 
you should get to know your data very well. 
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Sharding a New or Existing Collection 


Once you have selected a shard key, you are ready to shard your data. 


Quick Start 


If you’re looking to set up a cluster to play around with as fast as possible, you can set 
one up in a minute or two using the mongo-snippets repository on Github. It’s a little 
lacking in documentation, but this repository is basically a collection of useful scripts 
for users. Of particular interest is simple-setup.py, which automatically starts, config- 
ures, and populates a cluster (locally). 


To run this script, you’ll need to have the MongoDB Python driver. If you do not have 
it installed, you can install it (on “NIX systems) by running: 


$ sudo easy install pymongo 


Once Pymongo is installed, download the mongo-snippets repository and run the fol- 
lowing command: 


$ python sharding/simple-setup.py --path=/path/to/your/mongodb/binaries 


There are a number of other options available—run python sharding/simple-setup.py 
--help to see them. This script is a bit finicky, so make sure to use the full path 
(e.g., /home/user/mongo-install, not ~/mongo-install). 


simple-setup.py starts up a mongos on localhost:27017, so you can connect to it with 
the shell to play around. 


If you are interested in setting up a serious-business cluster, read on. 


Config Servers 


You can run either one or three configuration servers. We’ll be using three config serv- 
ers, as that’s what you should do whenever you’re in production. 





Va 

， 
SS “One or three” is a weird and somewhat arbitrary restriction, but the 
aS rationale is that one is good for testing, and three is good for production. 
~~ 4/8 Two is more than people would want to test with and not enough for 





` production. 


You can’t run an arbitrary number because their interactions are com- 
plex, and the programming and logic of what to do if N out of M config 
servers are down is difficult. MongoDB probably will support any num- 
ber of config servers in the future, but it’s not an immediate priority. 
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Setting up configuration servers is pretty boring because they’re just vanilla mongod 
instances. The only important thing to note when setting up config servers is that you 
want some of them up all of the time, so try to put them in separate failure domains. 


Let’s say we have three data centers: one in New York, one in San Francisco, and one 
on the moon. We start up one config server in each center. 


$ ssh ny-01 
ny-01$ mongod 


$ ssh sf-01 
sf-01$ mongod 


$ ssh moon-01 
moon-01$ mongod 


That’s it! 


You might notice a slight problem with this setup. These servers, which are supposed 
to be intimately connected to each other, have no idea that the others exist or that they 
are even config servers. This is fine—we’re going to hook them up in a moment. 


servers. Configuration servers do not use the same replication mecha- 
nism as “normal” mongod replication and should not be started as rep- 
lica sets or master-slave setups. Just start config servers as normal, 
unconnected mongods. 


Sometimes, people assume that they have to set up replication on config 


When you start up your config servers, feel free to use any of the options listed under 
“General Options” when you run mongod --help, except for --keyFile and --auth. 
Sharding does not support authentication at the moment, although this should change 
midway-through 1.9. 


It’s not a particularly good idea to run it with --quiet because you want to be able to 
figure out what’s going on if something goes wrong. Instead of --quiet, use --logpath 
<file> and --logappend to send the logs somewhere so you'll have them if you run into 
problems. 


The Sharding options apply to shards, not the configuration servers, so ignore those. 
You don’t need to use any of the other options (under Replication, Replica set, or 
Master/slave) because you didn’t start up your config servers with replication, right? 


mongos 


The next step is starting up a mongos. A sharded setup needs at least one mongos 
but can have as many as you'd like. Keep in mind that you will have to (or at least 
should) monitor all of the mongos processes you spin up, so you probably don’t want 
thousands, but one mongos per application server usually is a good number. So, we’ll 
log on to our application server and start up our first mongos. 
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$ ssh ny-02 
ny-01$ mongos --configdb ny-01,sf-01,moon-01 


Press Enter, and now all the config servers know about each other. The mongos is like 
the host of the party that introduces them all to each other. 


You now have a trivial cluster. You can’t actually store any data in it (configuration 
servers only store configuration, not data), but other than that, it’s totally functional. 


As you might want to use your database to read or write data, let’s add some data 
storage. 


Shards 


All administration on a cluster is done through the mongos. So, connect your shell to 
the mongos process you started. 

$ mongo ny-02:27017/admin 

MongoDB shell version: 1.7.5 


connecting to: admin 
> 


Make sure you’re using the admin database. Setting up sharding requires commands 
to be run from the admin database. 


Once you’re connected, you can add a shard. There are two ways to add a shard, 
depending on whether the shard is a single server or a replica set. Let’s say we have a 
single server, sf-02, that we’ve been using for data. We can make it the first shard by 
running the addShard command: 


> db.runCommand({"addShard" : "sf-02:27017"}) 
{ "shardAdded" : "shardoooo", "ok" : 1 } 


This adds the server to the cluster. Now you can start storing and querying for data. 
(MongoDB will give you an error if you attempt to store data before you have any shards 
to put it on, for obvious reasons.) 


In general, you should use a replica set, not a single server, for each shard. Replica sets 
will give you better availability. To add a replica set shard, you must give addShard a 
string of the form "setName/seed1[ , seed2[,seed3[,...]]]". That is, you must give the 
set name and at least one member of the set (mongos can derive the other members as 
long as it can connect to someone). 


For example, if we had a replica set creatively named replica set “rs” with members 
rsl-a, rs1-b, and rs1-c, we could say: 


> db.runCommand({"addShard" : "rs/rsi-a,rsi1-c"}) 
{ "shardAdded" : "rs", "ok" : 1 } 


Notice that we ended up with a much nicer name this time! (I was the one who pro- 
grammed it to pick up on the replica set name, so I’m particularly proud of it.) If you 
add a replica set, its name will become the shard name. 
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You can name a shard anything you want. If you don’t want the default, 
use the name option when you add a shard. 








> db.runCommand({"addShard" : "sf-02:27017", "name" : "Golden Gate shard"}) 
{ "shardAdded" : "Golden Gate shard", "ok" : 1 } 

> db.runCommand({"addShard" : “seti/rsi-a,rsi-b", "name" : "replicaSet1"}) 
{ "shardAdded" : "replicaSeti", "ok" : 1 } 


You'll have to refer to shards by name occasionally (see Chapter 5), so 
don’t make the name too crazy or long. 


Limiting shard size 


By default, MongoDB will evenly distribute data between shards. This is useful if 
yow’re using a bunch of commodity servers, but you can run into problems if you have 
one gargantuan machine with 10 terabytes and one ho-hum machine with a few hun- 
dred gigabytes. If your servers are seriously out of balance, you should use the max 
Size option. This specifies the maximum size, in megabytes, that you want the shard 
to grow to. 


Keep in mind that maxSize is more of a guideline than a rule. MongoDB will not cap 
off a shard at maxSize and not let it grow another byte, but rather it'll stop moving data 
to the shard and possibly move some data off. If it feels like it. So aim a bit low here. 


maxSize is another option for the addShard command, so if you want to set a shard to 
only use 20GB, you could say: 
> db.runCommand({"addShard" : "sfo/server1,server2", "maxSize" : 20000}) 


In the future, MongoDB will automatically figure out how much space it has to work 
with on each shard and plan accordingly. In the meantime, use maxSize to give it a hint. 


Now you have a fully armed and operational cluster! 


Databases and Collections 


If you want MongoDB to distribute your data, you have to let it know which databases 
and collections you want to distribute. Start with the database. You have to tell Mon- 
goDB that a database can contain sharded collections before you try to shard its col- 
lections. 
Let’s say we’re writing a blog application, so all of our collections live in the blog da- 
tabase. We can enable sharding on it with the command: 

> db.adminCommand({"enableSharding" : "blog"}) 

"ok" : 1 } 

Now we can shard a collection. To shard a collection, you must specify the collection 
and shard key. Suppose we were sharding on {"date" : 1, "author" : 1}. 


> db.adminCommand({"shardCollection" : "blog.posts", key : {"date" : 1, "author" : 1}} 
{ "collectionSharded" : "blog.posts", "ok" : 1 } 
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Note that we include the database name: blog.posts, not posts. 


If we are sharding a collection with data in it, the data must have an index on the shard 
key. All documents must have a value for the shard key, too (and the value cannot be 
null). After you’ve sharded the collection, you can insert documents with a null shard 
key value. 


Adding and Removing Capacity 


As your application continues to grow, you'll need to add more shards. When you add 
a shard, MongoDB will start moving data from the existing shards to the new one. Keep 
in mind that moving data puts added pressure on shards. MongoDB tries to do this as 
gently as possible; it slowly moves one chunk at a time, then tries again later if the server 
seems busy. However, no matter how delicately MongoDB does it, moving chunks adds 
load. 


This means that if you wait until your cluster is running at capacity to add more shards, 
adding a new shard can bring your application to a grinding halt through a chain re- 
action. Say your existing shards are just about maxed out, so you bring up a new shard 
to help with the load. The balancer pokes Shard 1 and asks it to send a chunk to the 
new shard. Shard 1 has just enough memory to keep your application’s working set of 
data in RAM, and now it’s going to have to pull a whole chunk into memory. The data 
that your application is using starts getting shunted out of RAM to make room for the 
chunk. This means that your application starts having to do disk seeks and MongoDB 
is doing disk seeks for chunk data. As queries start taking longer, requests begin to pile 
up, exacerbating the problem (see Figure 3-2). 


The lesson? Add shards while you still have room to maneuver. If you no longer have 
that room, add shards in the middle of the night (or at another non-busy time). If you 
don’t have a non-busy time and you waited too long, there are a couple of ways to hack 
around it, but they are neither fun nor easy. (You can manually create a Frankenstein 
shard from backups of your existing shard, manually change the config.chunks collec- 
tion, and restart your whole cluster—this is obviously not recommended.) Add shards 
early and often. 


So! How do you add shards? The same way that you added the first shard above, with 
the addShard command. 


One interesting thing about adding subsequent shards is that they don’t have to be 
empty. They cannot have databases that already exist in the cluster, but if your cluster 
has a foo database and you add a shard with a bar database, that’s fine, as the config 
servers will pick up on it and it’ll pop up in cluster info. Therefore, if you want, you 
can bring together a couple different systems into one large, sharded cluster. 
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Figure 3-2. Moving chunks can force data out of RAM, making more requests hit disk and slowing 
everything down 


Removing Shards 


Sometimes removing shards comes up. Someone might shard too early or they realize 
that they chose the wrong shard key, so they want to get everything back onto one 
shard, dump, restore, and try again. You might just want to take certain servers offline. 
The removeShard command lets you take a shard out of the cluster. 


> db.runCommand({removeShard : "Golden Gate shard"}) 


{ 
"msg" : "draining started successfully", 
"state" : "started", 
"shard" : "Golden Gate shard", 
"ok" : 1 
} 


Note that the message says “started successfully.” It has to move all of the information 
that was on this shard to other shards before it can remove this shard. As mentioned 
above, moving data from shard to shard is pretty slow. The removeShard command 
returns immediately, and you must poll it to find out if it has finished. If you call it 
again, you'll see something like: 
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> db.runCommand({removeShard : "Golden Gate shard"}) 


"msg" : "draining ongoing", 
"state" : "ongoing", 
"remaining" : { 
"chunks" : NumberLong(2), 
"dbs" : NumberLong(1) 
b 
"ok" : 1 


} 


Once it’s done, its status will change to “completed.” Then, you can safely shut down 
the shard (or use it as a non-sharded MongoDB server). 


> db.runCommand({removeShard : "Golden Gate shard"}) 


{ 
"msg" : "removeshard completed successfully", 
"state" : "completed", 
"shard" : "Golden Gate shard", 
"ok" : 1 
} 


This means that shard has been completely drained and may be shut down or used for 
other purposes. 


Changing Servers in a Shard 


If you’re using a replica set, you can add or remove servers from the replica set and your 
mongos will pick up on the change. To modify your replica set in a cluster, do the exact 
same thing you would do if it was running independently: connect to the primary 
(not through mongos) and make any configuration changes you need. 
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CHAPTER 4 
Working With a Cluster 





Querying a MongoDB cluster is usually identical to querying a single mongod. However, 
there are some exceptions that are worth knowing about. 


Querying 


If you are using replica sets as shards and a mongos version 1.7.4 or more recent, you 
can distribute reads to slaves in a cluster. This can be handy for handling read load, 
although the usual caveats on querying slaves apply: you must be willing to get older 
data. 


To query a slave through mongos, you must set the “slave okay” option (basically 
checking off that you’re okay with getting possibly out-of-date data) with whatever 
driver you’re using. In the shell, this looks like: 


> db.getMongo().setSlave0k() 


Then query the mongos normally. 


“Why Am | Getting This?” 


When you work with a cluster, you lose the ability to examine an entire collection as 
a single “snapshot in time.” Many people don’t realize the ramifications of this until it 
hits them in the nose, so we’ll go over some of the common ways it can affect applica- 
tions. 


Counting 


When you do a count on a sharded collection, you may not get the results you expect. 
You may get quite a few more documents than actually exist. 


The way a count works is the mongos forwards the count command to every shard in 
the cluster. Then, each shard does a count and sends its results back to the mongos, 
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which totals them up and sends them to the user. If there is a migration occurring, 
many documents can be present (and thus counted) on more than one shard. 


When MongoDB migrates a chunk, it starts copying it from one shard to another. It 
still routes all reads and writes to that chunk to the old shard, but it is gradually being 
populated on the other shard. Once the chunk has finished “moving,” it actually exists 
on both shards. As the final step, MongoDB updates the config servers and deletes the 
copy of the data from the original shard (see Figure 4-1). 





Shard B 














Figure 4-1. A chunk is migrated by copying it to the new shard, then deleting it from the shard it came 
from 


Thus, when data is counted, it ends up getting counted twice. MongoDB may hack 
around this in the future, but for now, keep in mind that counts may overshoot the 
actual number of documents. 


Unique Indexes 


Suppose we were sharding on email and wanted to have a unique index on username. 
This is not possible to enforce with a cluster. 


Let’s say we have two application servers processing users. One application server adds 
a new user document with the following fields: 
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"id" : ObjectId("4d2a2e9f74de15b8306fe7d0") , 
"username" : "andrew", 
"email" : "awesome.guy@example.com" 


} 


The only way to check that “andrew” is the only “andrew” in the cluster is to go through 
every username entry on every machine. Let’s say MongoDB goes through all the shards 
and no one else has an “andrew” username, so it’s just about to write the document 
on Shard 3 when the second appserver sends this document to be inserted: 
{ 

"id" : ObjectId("4d2a2f7c56d1bb09196fe7d0"), 

"username" : "andrew", 

"email" : "cool.guy@example.com" 


} 


Once again, every shard checks that it has no users with username “andrew”. They still 
don’t because the first document hasn’t been written yet, so Shard 1 goes ahead and 
writes this document. Then Shard 3 finally gets around to writing the first document. 
Now there are two people with the same username! 


The only way to guarantee no duplicates between shards in the general case is to lock 
down the entire cluster every time you do a write until the write has been confirmed 
successful. This is not performant for a system with a decent rate of writes. 


Therefore, you cannot guarantee uniqueness on any key other than the shard key. You 
can guarantee uniqueness on the shard key because a given document can only go to 
one chunk, so it only has to be unique on that one shard, and it’ll be guaranteed unique 
in the whole cluster. You can also have a unique index that is prefixed by the shard key. 
For example, if we sharded the users collection on username, as above, but with the 
unique option, we could create a unique index on {username : 1, email : 1}. 


One interesting consequence of this is that, unless you’re sharding on _id, you can 
create non-unique _ids. This isn’t recommended (and it can get you into trouble if 
chunks move), but it is possible. 


Updating 


Updates, by default, only update a single record. This means that they run into the 
same problem unique indexes do: there’s no good way of guaranteeing that something 
happens once across multiple shards. If you’re doing a single-document update, it must 
use the shard key in the criteria (update’s first argument). If you do not, you'll get an 
error. 

> db.adminCommand({shardCollection : "test.x", key : {"y" : 1}}) 

{ "shardedCollection" : "test.x", "ok" : 1 } 

> 

> // works okay 


> db.x.update({y : 1}, {$set : {z : 2}}, true) 
> 





“Why Am I Getting This?” | 35 


> // error 
> db.x.update({z : 2}, {$set : {w : 4}}) 
can't do non-multi update with query that doesn't have the shard key 


You can do a multiupdate using any criteria you want. 


> db.x.update({z : 2}, {$set : {w : 4}}, false, true) 
> // no error 


If you run across an odd error message, consider whether the operation you’re trying 
to perform would have to atomically look at the entire cluster. Such operations are not 
allowed. 


MapReduce 


When you runa MapReduce on cluster, each shard performs its own map and reduce. 
mongos chooses a “leader” shard and sends all the reduced data from the other shards 
to that one fora final reduce. Once the data is reduced to its final form, it will be output 
in whatever method you’ve specified. 


As sharding splits the job across multiple machines, it can perform MapReduces faster 
than a single server. However, it still isn’t meant for real-time calculations. 


Temporary Collections 


In 1.6, MapReduce created temporary collections unless you specified the “out” option. 
These temporary collections were dropped when the connection that created them was 
closed. This worked well on a single server, but mongos keeps its own connection pools 
and never closes connections to shards. Thus, temporary collections were never cleaned 
up (because the connection that created them never closed), and they would just hang 
around forever, growing more and more numerous. 


If you’re running 1.6 and doing MapReduces, you’ll have to manually clean up your 
temporary collections. You can run the following function to delete all of the temporary 
collections in a given database: 

var dropTempCollections = function(dbName) { 


var target = db.getSisterDB(dbName) ; 
var names = target.getCollectionNames(); 


for (var i = 0; i < names.length; i++) { 


if (names[i].match(/tmp\.mr\./)){ 
target[names[i]].drop(); 


} 


In later versions, MapReduce forces you to choose to do something with your output. 
See the documentation for details. 
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CHAPTER 5 
Administration 





Whereas the last chapter covered working with MongoDB from an application devel- 
oper’s standpoint, this chapter covers some more operational aspects of running a 
cluster. Once you have a cluster up and running, how do you know what’s going on? 


Using the Shell 


As with a single instance of MongoDB, most administration on a cluster can be done 
through the mongo shell. 


Getting a Summary 


db. printShardingStatus() is your executive summary. It gathers all the important in- 
formation about your cluster and presents it nicely for you. 
> db.printShardingStatus() 


--- Sharding Status --- 
sharding version: { "id" : 1, "version" : 3 } 


shards: 

{ "id" : "shardoooo", "host" : "ubuntu:27017" } 

{ "id" : "shardooo1", "host" : "ubuntu:27018" } 

databases: 

{ "id" : "admin", "partitioned" : false, "primary" : "config" } 
{ "id" : "test", "partitioned" : true, "primary" : "shardoooo" } 


test.foo chunks: 
shard0001 15 
shard0000 16 
"id" : { $minkey : 1 } } -->> { "_id" : 0 } on : sharda { "t" : 2, "i" : 0} 
"id" : 0 } -->> { "_id" : 15074 } on : shard1 { "t" : 3, "i" : 0 } 

"id" : 15074 } -->> { "_id" : 30282 } on : shardı { "t" : 4, "i" : 0 } 
"id" : 30282 } -->> { "_id" : 44946 } on : sharda { "t" : 5, "i" : 0 } 
"id" : 44946 } -->> { "_id" : 59467 } on : sharda { "t" : 7, "i" : 0} 
"id" : 59467 } -->> { "_id" : 73838 } on : shardı { "t" : 8, "i" : 0} 
.. some lines omitted ... 
"id" : 412949 } -->> { "_id" : 426349 } on : shardi { "t" : 6, "i" : 4 
"id" : 426349 } -->> { "_id" : 457636 } on : shard1 { "t" : 7, "i" : 2 


H 
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{ "id" : 457636 } -->> { "_id" : 471683 } on : shardi { "t" : 7, "i" : 4 } 

{ "id" : 471683 } -->> { "_id" : 486547 } on : shardi { "t" : 7, "i" : 6 } 

{ "id" : 486547 } -->> { "_id" : { $maxKey : 1 } } on : sharda { "t" : 7, "i" : 7 } 


db.printShardingStatus() prints a list of all of your shards and databases. Each sharded 
collection has an entry (there’s only one sharded collection here, test.foo). It shows you 
how chunks are distributed (15 chunks on shardooo1 and 16 chunks on shardooo0). 
Then it gives detailed information about each chunk: its range—e.g., { "_id" 
115882 } -->> { "id" : 130403 } corresponding to _ids in [115882, 130403)—and 
what shard it’s on. It also gives the major and minor version of the chunk, which you 
don’t have to worry about. 


Each database created has a primary shard that is its “home base.” In this case, the 
test database was randomly assigned shard0000 as its home. This doesn’t really mean 
anything—shard0001 ended up with more chunks than shard0000! This field should 
never matter to you, so you can ignore it. If you remove a shard and some database has 
its “home” there, that database’s home will automatically be moved to a shard that’s 
still in the cluster. 


db. printShardingStatus() can get really long when you have a big collection, as it lists 
every chunk on every shard. If you have a large cluster, you can dive in and get more 
precise information, but this is a good, simple overview when you’re starting out. 


The config Collections 


mongos forward your requests to the appropriate shard—except for when you query 
the config database. Accessing the config database patches you through to the config 
servers, and it is where you can find all the cluster’s configuration information. If you 
do have a collection with hundreds or thousands of chunks, it’s worth it to learn about 
the contents of the config database so you can query for specific info, instead of getting 
a summary of your entire setup. 


Let’s take a look at the config database. Assuming you have a cluster set up, you should 
see these collections: 


> use config 
switched to db config 
> show collections 
changelog 

chunks 

collections 
databases 
lockpings 

locks 

mongos 

settings 

shards 

system. indexes 
version 
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Many of the collections are just accounting for what’s in the cluster: 


config.mongos 
A list of all mongos processes, past and present 


> db.mongos.find() 

{ "id" : "ubuntu:10000", "ping" : ISODate("2011-01-08T10:11:23"), "up" : 0 } 
{ "id" : "ubuntu:10000", "ping" : ISODate("2011-01-08T10:11:23"), "up" : 20 } 
{ "id" : "ubuntu:10000", "ping" : ISODate("2011-01-08T10:11:23"), "up" : 1 } 


_id is the hostname of the mongos. ping is the last time the config server pinged it. 
up is whether it thinks the mongos is up or not. If you bring up a mongos, even if 
it’s just for a few seconds, it will be added to this list and will never disappear. It 
doesn’t really matter, it’s not like you’re going to be bringing up millions of mon- 
gos servers, but it’s something to be aware of so you don’t get confused if you look 
at the list. 


config.shards 
All the shards in the cluster 


config.databases 
All the databases, sharded and non-sharded 


config.collections 
All the sharded collections 


config.chunks 
All the chunks in the cluster 


config.settings contains (theoretically) tweakable settings that depend on the database 
version. Currently, config.settings allows you to change the chunk size (but don’t!) and 
turn off the balancer, which you usually shouldn’t need to do. You can change these 
settings by running an update. For example, to turn off the balancer: 


> db.settings.update({"_id" : "balancer"}, {"$set" : {"stopped" : true }}, true) 


If it’s in the middle of a balancing round, it won’t turn off until the current balancing 
has finished. 


The only other collection that might be of interest is the config.changelog collection. It 
is a very detailed log of every split and migrate that happens. You can use it to retrace 
the steps that got your cluster to whatever its current configuration is. Usually it is more 
detail than you need, though. 


“| Want to Do X, Who Do | Connect To?” 


If you want to do any sort of normal reads, writes, or administration, the answer is 
always “a mongos.” It can be any mongos (remember that they’re stateless), but it’s 
always a mongos—not a shard, not a config server. 


You might connect to a config server or a shard if you’re trying to do something unusual. 
This might be looking at a shard’s data directly or manually editing a messed up 
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configuration. For example, you'll have to connect directly to a shard to change a replica 
set configuration. 


Remember that config servers and shards are just normal mongods; anything you know 
how to do on a mongod you can do on a config server or shard. However, in the normal 
course of operation, you should almost never have to connect to them. All normal 
operations should go through mongos. 


Monitoring 


Monitoring is crucially important when you have a cluster. All of the advice for mon- 
itoring a single node applies when monitoring many nodes, so make sure you have read 
the documentation on monitoring. 


Don’t forget that your network becomes more of a factor when you have multiple 
machines. If a server says that it can’t reach another server, investigate the possibility 
that the network between two has gone down. 


If possible, leave a shell connected to your cluster. Making a connection requires Mon- 
goDB to briefly give the connection a lock, which can be a problem for debugging. Say 
a server is acting funny, so you fire up a shell to look at it. Unfortunately, the mongod 
is stuck in a write lock, so the shell will sit there forever trying to acquire the lock and 
never finish connecting. To be on the safe side, leave a shell open. 


mongostat 


mongostat is the most comprehensive monitoring available. It gives you tons of infor- 
mation about what’s going on with a server, from load to page faulting to number of 
connections open. 


If you’re running a cluster, you can start up a separate mongostat for every server, but 
you can also run mongostat --discover on a mongos and it will figure out every member 
of the cluster and display their stats. 


For example, if we start up a cluster using the simple-setup.py script described in Chap- 
ter 4, it will find all the mongos processes and all of the shards: 


$ mongostat --discover 


mapped vsize res faults locked % idx miss % conn time repl 
localhost :27017 0 105m 3m 0 0 0 2 22:59:50 RTR 
localhost :30001 80 175m 5m 0 0 0 3 22:59:50 
localhost :30002 0 95m 5m 0 0 0 3 22:59:50 
localhost :30003 0 95m 5m 0 0 0 3 22:59:50 
localhost:27017 0 105m 3m 0 0 0 2 22:59:51 RTR 
localhost:30001 80 175m 5m 0 0 0 3 22:59:51 
localhost: 30002 0 95m 5m 0 0 0 3 22:59:51 
localhost :30003 0 95m 5m 0 0 0 3 22:59:51 
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Tve simplified the output and removed a number of columns because I’m limited to 80 
characters per line and mongostat goes a good 166 characters wide. Also, the spacing 
is a little funky because the tool starts with “normal” mongostat spacing, figures out 
what the rest of the cluster is, and adds a couple more fields: qr|qw and ar|aw. These 
fields show how many connections are queued for reads and writes and how many are 
actively reading and writing. 


The Web Admin Interface 


If you’re using replica sets for shards, make sure you start them with the --rest option. 
The web admin interface for replica sets (http://localhost:28017/_replSet, if mongod is 
running on port 27017) gives you loads of information. 


Backups 


Taking backups on a running cluster turns out to be a difficult problem. Data is con- 
stantly being added and removed by the application, as usual, but it’s also being moved 
around by the balancer. If you take a dump of a shard today and restore it tomorrow, 
you may have the same documents in two places or end up missing some documents 
altogether (see Figure 5-1). 


The problem with taking backups is that you usually only want to restore parts of your 
cluster (you don’t want to restore the entire cluster from yesterday’s backup, just the 
node that went down). If you restore data from a backup, you have to be careful. Look 
at the config servers and see which chunks are supposed to be on the shard you’re 
restoring. Then only restore data from those chunks using your backups (and mon- 
gorestore). 


If you want a snapshot of the whole cluster, you would have to turn off the balancer, 
fsync and lock the slaves in the cluster, take dumps from them, then unlock them and 
restart the balancer. Typically people just take backups from individual shards. 


Suggestions on Architecture 


You can create a sharded cluster and leave it at that, but what happens when you want 
to do routine maintenance? There are a few extra pieces you can add that will make 
your setup easier to manage. 


Create an Emergency Site 


The name implies that you’re running a website, but this applies to most types of ap- 
plication. If you need to bring your application down occasionally (e.g., to do mainte- 
nance, roll out changes, or in an emergency), it’s very handy to have an emergency site 
that you can switch over to. 
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Figure 5-1. Here, a backup is taken before a migrate. If the shard crashes after the migrate is complete 
and restored from backup, the cluster will be missing the migrated chunk. 


The emergency site should not use your cluster at all. If it uses a database, it should be 
completely disconnected from your main database. You could also have it serve data 
from a cache or be a completely static site, depending on your application. It’s a good 
idea to set up something for users to look at, though, other than an Apache error page. 


Create a Moat 


A excellent way to prevent or minimize all sorts of problems is to create a virtual moat 
around your machines and control access to the cluster via a queue. 
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A queue can allow your application to continue handling writes in a planned outage, 
or at least prevent any writes that didn’t quite make it before the outage from getting 
lost. You can keep them on the queue until MongoDB is up again and then send them 
to the mongos. 


A queue isn’t only useful for disasters—it can also be helpful in regulating bursty traffic. 
A queue can hold the burst and release a nice, constant stream of requests, instead of 
allowing a sudden flood to swamp the cluster. You can also use a queue going the other 
way: to cache results coming out of MongoDB. 


There are lots of different queues you could use: Amazon’s SQS, RabbitMQ, or even a 
MongoDB capped collection (although make sure it’s on a separate server than the 
cluster it’s protecting). Use whatever queue you’re comfortable with. 


Queues won’t work for all applications. For example, they don’t work with applications 
that need real-time data. However, if you have an application that can stand small 
delays, a queue can be useful intermediary between the world and your database. 


What to Do When Things Go Wrong 


As mentioned in the first chapter, network partitions, server crashes, and other prob- 
lems can cause a whole variety of issues. MongoDB can “self-heal,” at least temporarily, 
from many of these issues. This section covers which outages you can sleep through 
and which ones you can’t, as well as preparing your application to deal with outages. 


A Shard Goes Down 


Ifan entire shard goes down, reads and writes that would have hit that shard will return 
errors. Your application should handle those errors (itll be whatever your language’s 
equivalent of an exception is, thrown as you iterated through a cursor). For example, 
if the first three results for some query were on the shard that is up and the next shard 
containing useful chunks is down, you’d get something like: 


> db.foo.find() 


{ "id" 1 } 
{ "id" : 2 } 
{ "Gd" :3 } 


error: mongos connectionpool: 
connect failed ny-01:10000 : couldn't connect to server ny-01:10000 


Be prepared to handle this error and keep going gracefully. Depending on your appli- 
cation, you could also do exclusively targeted queries until the shard comes back online. 


Support will be added for partial query results in the future (post-1.8.0), which will 
only return results from shards that are up and not indicate that there were any prob- 
lems. 
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Most of a Shard Is Down 


If you are using replica sets for shards, hopefully an entire shard won’t go down, but 
merely a server or two in the set. If the set loses a majority of its members, no one will 
be able to become master (without manual rejiggering), and so the set will be read-only. 
Ifa set becomes read-only, make sure your application is only sending it reads and using 
slaveOkay. 


If you’re using replica sets, hopefully a single server (or even a few servers) failing won’t 
affect your application at all. The other servers in the set will pick up the slack and your 
application won’t even notice the change. 
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is out-of-date and updates it. However, it shouldn’t have an impact on 
what’s actually happening—it’s just a lot of sound and fury. This has 
been fixed for 1.8; mongos is much smarter about updating replica set 
configurations. 


Config Servers Going Down 


Ifa config server goes down, there will be no immediate impact on cluster performance, 
but no configuration changes can be made. All the config servers work in concert, so 
none of the other config servers can make any changes while even a single of their 
brethren have fallen. The thing to note about config servers is that no configuration 
can change while a config server is down—you can’t add mongos servers, you can’t 
migrate data, you can’t add or remove databases or collections, and you can’t change 
replica set configurations. 


If a config server crashes, do get it back up so that your config can change when it needs 
to, but it shouldn’t affect the immediate operation of your cluster at all. Make sure you 
monitor config servers and, if one fails, get it right back up. 


Having a config server go down can put some pressure on your servers if there is a 
migrate in progress. One of the last steps of the migrate is to update the config servers. 
Because one server is down, they can’t be updated, so the shards will have to back out 
the migration and delete all the data they just painstakingly copied. If your shards aren’t 
overloaded, this shouldn’t be too painful, but it is a bit of a waste. 


Mongos Processes Going Down 


As you can always have extra mongos processes and they have no state, it’s not too big 
a deal if one goes down. The recommended setup is to run one mongos on each app- 
server and have each appserver talk to its local mongos (Figure 5-2). Then, if the whole 
machine goes down, no one is trying to talk to a mongos that isn’t there. 
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Figure 5-2. An appserver running a mongos. 


Have a couple extra mongos servers out there that you can fail over to if one mongos 
process crashes while the application server is still okay. Most drivers let you specify a 
list of servers to connect to and will try them in order. So, you could specify your 
preferred mongos first, then your backup mongos. If one goes down, your application 
can handle the exception (in whatever language you’re using) and the driver will au- 
tomatically shunt the application over to your backup mongos for the next request. 


You can also just try restarting a crashed mongos if the machine is okay, as they are 
stateless and store no data. 


Other Considerations 


Each of the points above is handled in isolation from anything else that could go wrong. 
Sometimes, if you have a network partition, you might lose entire shards, parts of other 
shards, config servers, and mongos processes. You should think carefully about how 
to handle various scenarios from both user-facing (will users still be able to do any- 
thing?) and application-design (will the application still do something sensible?) per- 
spectives. 


Finally, MongoDB tries to let a lot go wrong before exposing a loss of functionality. If 
you have the perfect storm (and you will), you’ll lose functionality, but day-to-day 
server crashes, power outages, and network partitions shouldn’t cause huge problems. 
Keep an eye on your monitoring and don’t panic. 
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CHAPTER 6 
Further Reading 





If you follow the advice in the preceding chapters, you should be well on your way to 
an efficient and predictable distributed system that can grow as you need. If you have 
further questions or are confused about anything, feel free to email me at 
kristina@10gen.com. 


If you’re interested in learning more about sharding, there are quite a few resources 
available: 


。 The MongoDB wiki has a large section on sharding, with everything from config- 
uration examples to discussions of internals. 

e The MongoDB user list is a great place to ask questions. 

。 There are lots of useful little pieces of code in the mongo-snippets repository. 


。 Boxed Ice runs a production MongoDB cluster and often writes useful articles in 
their blog about running MongoDB. 

。 If you’re interested in reading more about distributed computing theory, I highly 
recommend Leslie Lamport’s original Paxos paper, which is an entertaining and 
instructive read. 


Also, if you enjoyed this, I write a blog that mostly covers advanced MongoDB topics. 
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